On Nov 10, 2005, at 12:48 PM, Allen Gilliland wrote:
On Thu, 2005-11-10 at 06:41, Dave Johnson wrote:
On Nov 9, 2005, at 11:37 PM, Allen Gilliland wrote:
!! Release numbers and Versions
Release number convention is __major.feature.minor-patch__
I think that's a bit confusing. Most other software uses
Major.Minor.Patch, so I say we stick to that. The main reason being
that I think it's a little misleading to offer 1.2.0 -> 1.2.1 as a
release which could have some fairly significant changes. for example
i am rewriting our presentation caching for the next release, and even
though it doesn't require a schema change i wouldn't put it in a
release called 2.0.1.
Confusing!?! That's what how the JDK numbering works! Hmmm... on second
thought, never-mind.
I say we just go back to the old plan since we don't seem to like the
idea of limiting db schema changes to major releases. That means we
follow Major.Minor.Patch release numbering. Most releases will be
Minor and may include small db changes which allow for rollbacks.
Major releases can have bigger changes which may not be compatible
with previous versions. In some extreme cases we'll offer patch
releases, but I don't think they should be necessary.
Is that cool? I guess it's basically the plan we have now, except
that we are allowing db changes in minor releases as long as they are
backwards compatible.
Cool. I think that's the consensus, based on Matt's +1 to patch
numbering and Elias wanting the possibility of tagging before 3.0. I
added the words "minor backwards compatible database schema changes" to
the description of a minor release and I think we're done with the
release plan discussion.
- Dave
