Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
That is a reason for increasing minor version, but not for maintaining
parallell branches for years.
If we don't maintain the "old" 2.1.x branch, what about all its users?
Do you want to force them to migrate to 2.2? That's simply not
realistic. We should be able to provide bug fixes for all those out
there using our project.
Have never disputed that we have to maintain 2.1 for some while and that
we must go the alpha->beta->stable cycle for 2.2.
My message is that I fail to see that we gained anything from creating
an unstable development branch and that we should avoid doing that
mistake in the future.
If we want to remove deprecated code, we have a routine for that: wait
long enough time, so that everyone have had the chance to do anything,
vote about it, remove the code and step up the minor number. If we at
that point feel that we still need to maintain the previous version, it
means that we removed the deprecated code to early and the we probably
should readd it and schedule the removal to the next minor release.
Mainteining two versions because of to early removal of deprecated code
seem like a bad idea.
For API changes the situation is obviously more complicated, so we must
really know what we are doing and if possible make it possible to use
the new and the old in parallell for some while.
If this can't be done, we need to maintain an old branch for a period.
But in this case we should try to decide for how long time we maintain
it and remove it afterwards. And it should IMO be marked as a
compability branch rather than the stable one.
IMO we should really try to let trunk contain the stable branch in the
future. The idea of an unstable development doesn't seem to fit well
with our *actual* community dynamics. And it doesn't fit well with agile
development methods either. And it is IMO highly questionable if it has
done anything good for us since 1.0->2.0. To me it rather seem to hurt us.
/Daniel
