apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject [vote] Adopt n.{odd} unstable release versioning?
Date Tue, 09 Oct 2007 17:48:48 GMT
Folks, it might be time to bring this up again...

We have one essential flaw in our versioning approach, it really
doesn't give us a lot of wiggle room after we commit a new API and
release the first tarball, until version 2.0 rolls out, to fix things.

I'd like to advocate for taking httpd's approach, and allowing all
newly introduced API's to remain in flux for the lifespan of a 1.{odd}.n
alpha/beta unstable release series.

This would give a chance for adopters to try out and provide feedback to
our newest API's, and more importantly, provide essential feedback that
we need to improve them before they are declared as general availability.

To that end, n.{odd} would be declared a dev/unstable version, while the
changes that we ultimately agree are GA would proceed to an n.{even}.0
release.  This is more in the spirit of 0.9, however it would never be
'finished' as a release, but abandoned upon the GA release n.{even}.0.

This would let us put 1.3.0 out there in the next week as alpha and begin
to assess our new encryption, multicast and thread pool features, without
the worry that they must be 'perfect' in this alpha.

On to the vote;

 [ ] retain versioning as-is, e.g. 1.3.0 is our next potential 'GA release'
 [ ] adopt n.{odd} unstable versioning, e.g. 1.4.0 will be the 'GA release'

Bill

Mime
View raw message