Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
My original idea was to release 2.1.8 after the GT, so announcing the
code freeze the week after the GT and releasing one week later. In the
last years, we had the famous bug hunt at the GT and fixed/improved
several things. This year we have two days for the hackathon so we
should be able to do even more.
But we can release sooner if required; I think the current state is very
stable.
I think from 2.1.8 we should simply release every two months. So
everyone (developers and users) have a fixed date. So this is a little
bit more of agile development as we are using fixed sprints :)
Of course if there are showstoppers we will make an exception.
Although I agree with the general principle of shorter release cycles,
we have to define a policy regarding new features introduced in these
frequent releases and the associated contracts. Again, stable / unstable
state, but at a finer intra-block level.
Let's take an example with the new Location stuff. It's very cool and a
lot of people will want to use it. However, we may not consider the API
totally finished (there are still a few minor changes I'd like to do for
it to be cleaner and more straightforward). What if we make a release
now? The contracts will have changed a bit in the next release!
So this leads back to a discussion we already had: marking some APIs as
internal, so that people are warned that they should not base their code
on it. The internal status can be used for things that are really
internal (like all the environment handling stuff) and things that are
fully functionnal (i.e. "stable" from a bug point of view) but on which
we still reserve the right to do some modifications.
Another solution of course would be to use branches, but this isn't very
practical for fine-grained things like outlined above.
Just some thoughts...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
