Hi Ian,
just three quick points on this:
1. I'm not sure you're right about 15.53 - the previous stable
release (for windows at least) was 15.5.
2. Aaron did ask the question whether 15.6 or 16.0 would be better
and the view that prevailed I think was that the changes he made
were not big enough to warrant going to a new version number.
(However, this was before the changes had actually been made, and
it may be Aaron ended up doing more than he had anticipated...)
3. The kind of thing the 'openpoplog' team are thinking about
probably do warrant a new version number, but my own view is that
we should also go with a new name and start again at 1 (or 0?) ie
OpenPoplog 1.0.0
I didn't know the even/odd thing - sounds like a good idea to me.
Roger
Ian Rogers wrote:
>>On the basis of Waldek's work I have managed to recompile, link
>>and run poplog version 15.53, including creating the usual
>>...
>>When I get time I'll try to package a 64bit version of
>>Poplog v15.6
>>
>>
>
>I enjoy following this group, though mostly out of nostalgia as I have too
>many other projects going on to contribute much right now, but I feel
>compelled to stick my oar in on this issue [and it's turned into a bit of
>an essay, sorry].
>
>I must have missed the decision to change the version number from 15.53 to
>15.6 (and if anyone can dig up the rationale behind it I'd be very
>grateful) but it seems a bit silly and very broken for an OSS project!
>
>v15.53 was *not* the 3rd release of version 5 of major-version 15, it
>really was release 53 of version 15. So to increment release 53 to release
>6 seems wrong (and I'm sure, in some archive somewhere, there's an
>original v15.6 released years ago!).
>
>But there is a better way...
>
>*All* other open source projects I've come across use the three-part
>major.version.release numbering scheme.
>
>The major number almost never changes unless there's a vast change to the
>application's architecture. The version typically changes roughly once a
>year (though this can vary from a few months to a few years) and also
>follows the "even/odd" rule which can be *very* useful. The release number
>changes every time any bugfix or change is made (so may increment every
>few days).
>
>What is the "Even/odd rule"? By convention even numbered versions are
>"stable" or "public" versions. The only changes made to stable versions
>are bugfixes! Odd numbered versions are "unstable" or "development"
>version where new functionality is developed, tried, discussed etc.
>Typically, bugfixes are developed on the odd-version and then "back fixed"
>into the even-version when the fix is seen to be correct.
>
>This is extremely useful. Non-developers, ie. users, of the system only
>ever install even numbered versions and get a nice stable environment at
>the cost of not being on the bleeding edge. The likes of Aaron, Waldek
>etc. may prefer odd numbered versions :-)
>
>Teams doing ports will choose the most appropriate version. Ie. sometimes
>it will be easier to port a stable, non-moving, target but sometimes a
>port attempt uncovers a bug so fundamental that new functionality, ie.
>development of a odd numbered version, is required to continue.
>
>As developers add functionality to the odd numbered version there will
>come a time where, by consensus, they agree to create a "release
>candidate". At that point e.g. v16.1.67 becomes v16.1.rc1 and only
>regression testing and bug fixes happen until it is of a standard to be
>released as v16.2.0 for example.
>
>So, please please please can you (whoever controls numbering - Aaron?)
>consider renumbering v15.6 to v16.0.0 (v16 is required to start the new
>version.release scheme) and quietly forget v15.6 as a bad idea. It's
>likely you'll also want to construct a copy as v16.1.0 at the same time
>for developers.
>
>Thanks,
>
>Ian.
>
>
>
|