Versioning is something almost every developer hates
to do (as it is boring work he doesn't need), but it
is also something that is vital for every client
programmer.
When software is alpha, it is okay to not have a
versioning system in place. For beta software
(where beta means: we will create a supported
release based on this code once we have tested
it enough and removed bugs), versioning is vital,
especially when there are multiple components
(framework, unstable framework, cornerstone,
phoenix) that make up a system.
Therefore, I propose to adopt some kind of versioning
system, and make following it obligatory.
Here's the idea (borrowed from the linux people):
an even number means "more stable" while an odd number
means "less stable". This leads to:
4.0 means a stable, final release
4.0.x means an update or bugfix of 4.0
4.1 means a beta that adds new features to 4.0,
where the important interfaces (i.e. lifecycle)
are not broken.
4.2 is the stable release of 4.1. It is usually
a little better than 4.0.x.
etc etc.
Deprecation is possible within a version number,
whereas removal of an interface or public class
requires a new version number (i.e. from 4 to 5).
Alpha code has a first version number that is
uneven. Alpha code that moves to beta code
gets a "b" appended to its version number. So:
3.3 means alpha code without any support which is
not guaranteed to even run
3.4 means alpha code that can compile and run with
relatively few errors, but that gets no support
at all.
3.4.x means a small change from 3.4.
3.5 means a bigger change from 3.4.
3.8b means a beta version of 3.7. It is not guaranteed
that the next version will be 4.0 (i.e. stable),
though. We can also go for 3.9 which is again alpha,
then 3.10 and then 3.10b which is a beta again.
but: the only obligatory for alpha code is that it
uses an uneven first version number.
I realise most of you hate a straight-jacket like
this (I do to), but you'll probably recognise the
advantages as well. I drafted it all this way
because many people are somewhat familiar with it.
----------------------------------------------------------------
What this means in a concrete way (not solid and not
part of my proposal (yet)):
- the current framework code in the avalon proposal is
3.7. Once the dust settles, it is moved to 3.8b (beta).
It'll stay there for a while for testing, and will then
go to 4.0. (note: while I'm not very happy with the
current proposed setup, I recognise the need for a beta
real soon so I'll shut up and accept)
- the rest of the code in that proposal is 3.3. It'll
take more than a few cycles 'till we get this to 4.0.
- I suggest we just synchronise phoenix and cornerstone
to have them follow these version numbers. So the current
phoenix and cornerstone are 3.2.x until they get updated
to work with the proposal code, and then they'll be 3.3
as well.
Once the specification implementation (i.e. avalon.*)
moves to 3.14b or something, we can start on building a
beta of phoenix and cornerstone. This means 4.0 of phoenix
and cornerstone will be released say 3 months after
the 4.0 for the Avalon implementation.
What it could mean as well:
- 5.x is a big move from all of this (if I have it my way
phoenix will be the RI of the specification), which will
lead to a
- 6.x that is truely broadly usable and stable.
- Hopefully many other Jakarta projects will like and accept
4.0 and they'll become avalon-enabled, which could then
lead to a wealth of programs available for/optimised for
avalon 6.x.
- 7.x and up will probably be reworkings of 6.x to be
compatible with the Java Server Framework JSR, and in
the end support for running on cellphones and playstations =)
--------------------------------------------------------------------
Anyway, can I have 3 hurrays (or at least some +1s) for the
adoption of a versioning system,
- where 3.x is alpha/beta code with some suggestions for versioning,
but where these are not obligatory?
- where 4.x is beta/stable code with a tight versioning
system?
here's mine for both: +1
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("[EMAIL PROTECTED]");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
