rethinking the "New" development changes
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.
If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Re: rethinking the "New" development changes
Actually, wouldn't any release, except for the initial 3.x.0, be bug fixes only? With the new versioning/development scheme in place, I would expect "feature creep" in any given 3.x branch be reduced to an absolute minimum, as new features would be introduced only with a new 3.x+1 release. Or are you leaving the door open for minor functionality changes? (Although I suppose it then boils down to the question what's considered a "bug").
Re: rethinking the "New" development changes
Technically that is correct.Eelke wrote:Actually, wouldn't any release, except for the initial 3.x.0, be bug fixes only?
-
- Registered User
- Posts: 653
- Joined: Wed Sep 21, 2005 3:01 pm
Re: rethinking the "New" development changes
my $0.02:Eelke wrote:Actually, wouldn't any release, except for the initial 3.x.0, be bug fixes only?
i don't see why stable releases can't grow new features, although the level of testing that goes into any such new feature should be considerably more than the level of testing this new feature gets on the bleeding edge.
presumably, these "new" features will be, nine times out of ten, backporting of features from a more advance release.
some examples to where such things are justified:
-- at some point last year, ICANN changed the definition of URI to include non-ascii (or rather, non-latin) characters. teaching phpbb to support these new URLs would be justified, IMO, (even all the way back to phpbb2).
-- something (e.g. spamming) becomes significant enough problem and a new feature (e.g. new captcha, or even a whole "captcha-plugin" infrastructure) can alleviate it, it can be justified to backport to older, "stable" versions, even though it's not a bug-fix.
IMO, the key is "common sense" rather than some hard-and-fast rules about what should and shouldn't be done.
peace.
Re: rethinking the "New" development changes
Absolutely. However, the need for this should in theory be alleviated to a great extent by more frequent feature releases, complete with a minor version number bump. To me, user expectations play an important role too. Just look at 3.0.6. To the casual observer (who may see an announcement on some tracking site, doesn't bother to read the description and only sees the version number), that looks simply like a maintenance release. Probably a few security fixes, some bug fixes, maybe some minor functionality enhancements over 3.0.5. In reality, it is a full-fledged feature release with various new features. To the outside world, this would have been far more obvious if it were designated 3.1. As I understand it, it would have been, had the decision to make the "development changes" been made before development on 3.0.6 started.
Of course, common sense should prevail, and if new features need to be introduced, but it doesn't warrant a minor version number bump (because the introduced changes are not substantial enough), by all means. Also, it boils down to the definition of "bug". One man's feature is another man's fixed bug. Just take the CAPTCHA plugin system as an example. The need became so high that, even though it is a substantial change in functionality, it could be considered a "bug fix".
Of course, common sense should prevail, and if new features need to be introduced, but it doesn't warrant a minor version number bump (because the introduced changes are not substantial enough), by all means. Also, it boils down to the definition of "bug". One man's feature is another man's fixed bug. Just take the CAPTCHA plugin system as an example. The need became so high that, even though it is a substantial change in functionality, it could be considered a "bug fix".