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