> I think the actual precedent is to go 0.9xx... as needed until you
> _can_ declare the 1.0. So it's more of a mindset thing to bump the
> number and get folks really working towards that 1 goal. You do not
> need to feel limited to only 9 releases. There can in fact remain an
> infinite number of releases between 0.90 and 1.x. :)
>
> I just can't figure out a good way to declare something as pre-1.4.0
> without confusing folks more, as in 1.3.x won't work as it is also
> false. So just keeping the same style as now and moving forward to
> 0.90 makes good sense to me. But what version numbers will you use
> post 1.4.0 for development releases? Would you go with 1.5.0-xxxx or
> similar for HEAD and 1.4.0-xxxx for the 1.4 release branch? That
> actually doesn't quite work, the 1.5 release branch would also end up
> 1.5.0-xxxx so something else will have to differentiate a dev release.
>
I agree that trying to stick with the api version we're aiming for is
probably very problematic as we'll have most 1.3 and 1.4 working, but a
bit of 1.5 and later a bit of 1.6 too, but without 100% 1.4, so it
doesn't mean much to the casual user I guess.
I'd tend to reuse an early proposition, with the date being included in
the release version. After all, we're in the same situation as the wine
guys, and they used a date as release version for quite some time iirc
and only recently they switched to 0.9.x because they feel that they
were close to a "mostly" working implementation (whatever "mostly" mean,
either for them or us).
So, having a classpath 0.200602 (or similar) as the next version could
be useable since it's > 0.20 from an raw ascii lexycographical order
(hence for packager), it's not a >= 1.0 version as we're still in the
process of getting "most" stuff working ("most" should include running
flawlessly the entire test suites of the major products imho [just
define "major product" and we're done ] ) and it includes an indicator
of the freshness of the release (with the date).
When we will all be happy with the advances, we may then switch to 0.9.x
with the adequate precision to fit enough release before the 1.0
my 0.02 euros
> You can of course internally continue with your same scheme and simply
> tag your production releases as corresponding to a particular java
> release and leave it at that. Doesn't look like anyone wants to do
> that though.
>
> Oh yes, if the packaging tools can't tell 1.4.0 is newer than 0.90
> then perhaps you'd want to bring about the package version change hell
> sooner rather than later.
>
> Brian
>
Olivier
