rethinking the "New" development changes

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The current feature release of phpBB 3 is 3.3/Proteus.
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.
User avatar
Eelke
Registered User
Posts: 606
Joined: Thu Dec 20, 2001 8:00 am
Location: Bussum, NL
Contact:

Re: rethinking the "New" development changes

Post by Eelke »

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").

ToonArmy
Registered User
Posts: 335
Joined: Fri Mar 26, 2004 7:31 pm
Location: Bristol, UK
Contact:

Re: rethinking the "New" development changes

Post by ToonArmy »

Eelke wrote:Actually, wouldn't any release, except for the initial 3.x.0, be bug fixes only?
Technically that is correct.
Chris SmithBlogXMOOhlohArea51WikiNo support via PM/IM
Image

code reader
Registered User
Posts: 653
Joined: Wed Sep 21, 2005 3:01 pm

Re: rethinking the "New" development changes

Post by code reader »

Eelke wrote:Actually, wouldn't any release, except for the initial 3.x.0, be bug fixes only?
my $0.02:

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.

User avatar
Eelke
Registered User
Posts: 606
Joined: Thu Dec 20, 2001 8:00 am
Location: Bussum, NL
Contact:

Re: rethinking the "New" development changes

Post by Eelke »

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".

Post Reply