Repository and release numbering changes

Hi everybody,

Since some time we've been discussing how our development model and
especially repository management should work.  The sandbox->staging
->bugfree->trunk does not quite reflect the way our actual development
happens.  It looks like after over a year of using this model there's
time for some refinement.

Changes proposed:
1. staging becomes trunk, bugfree disappears (so we only have trunk),
2. "branches" directory becomes writable for all developers,
3. releases will basically use two-number versions ie. 1.10, with
   possibility of making "bugfix" releases ie. 1.10.1 when necessary.

ad 1. We observed that bugfree pretty much always was simply a snapshot
  of staging, therefore release tags on bugfree could have actually be
  made directly on staging.  There also were no rules, nor pressure
  for migration of the code from bugfree to super-stable trunk, so
  the trunk was unused.  This change allows us to shorten the way code
  has to make to get into a release.

ad 2. There have always been discussions about when and how we should
  revert staging in case it was found broken.  Reverting code from
  staging means, among other things, that there is no longer a shared
  place where the broken code can be improved (ie. last time Etienne 
  made a copy of reverted code in his sandbox).

  After the change we will be able to copy current trunk (=staging)
  into ie. /sablevm/branches/trunk-broken-20050314 and continue to
  work on fixing the problems introduced supposedly during classpath
  merge.

  Any developer will also be able to create another shared branch
  in branches directory when he wants to more easily cooperate on
  it with other developers, while the code developed is not ready
  for inclusion into trunk yet.
  
ad 3. Along with staging->bugfree->trunk idea we had an idea of using
  even and odd middle numbers to distinguish development and stable
  releases.  This does not work with our development model, where we
  pretty much only have snapshots of our main development trunk.  OTOH
  having two-number releases seems to better ressemble the reality of
  continuously appearing development releases.

  Additionally we will be able to make small "bugfix" releases, ie.
  now we would release 1.10.1, for which we would not make an official
  release, but which would be mentioned on our web sites as the latest
  released version, and which would not contain serious bugs that 1.10
  (=1.1.10) had, but would contain an older class library.

I believe this new schema would give us more flexibility and ability to
cooperate on code (via shared read-write branches directory), while also
making it easier to actully keep trunk free of regressions.  And, what
probably the most important, it seems to be more in line with how our
development actually works.

If there's no objections, we'll implement the changes ASAP, especially
that we have a serious regression in staging that we should get rid of.

Comments?

				Grzegorz B. Prokopski
--
Grzegorz B. Prokopski <[email protected]>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/Features