Re: [Monotone-devel] Time for a release

[Thomas Keller]

Am 31.05.10 01:01, schrieb Thomas Keller:
> I'll give translators and testers a bigger time frame for this release
> (at least two weeks from now), because I'd like to switch the release
> numbering and make 0.48 become 1.0.0 as discussed in the other thread.
> So if you have some time and like to polish one or two things in the UI,
> then you're very welcome :)

I've just talked with Thomas Moschny on IRC and I listened again to his
and other people's concerns about switching too fast to 1.0. I think the
concerns are reasonable, so we've discussed this issue and concluded the
following:

* The next version of monotone will be named 0.99 and will be the last
  version before the final 1.0.0 is out

* The time frame between 0.99 and 1.0.0 won't be longer than a couple
  of weeks (probably not more than four) - enough to get feedback,
  flesh out remaining issues as well as polishing strings,
  documentation (wiki?) and other things which may arise.

* NO new features should be merged within this time frame. To not
  block other people's work too much, I'm proposing we create a new
  release branch for the work after 0.99 - named nvm.releases.1_0_0.
  This could later be used for bug fixes on the final 1.0.0 release
  as well and the normal development would continue to happen in nvm.

* Naturally every feature which is worked on nvm would get into the
  next minor version (after 1.0.0 this would be 1.1.0) which we would
  branch off from nvm if we decide that its stable enough.


Here are again the (adapted) rules when we'll raise the major / minor /
patch level in the future:

1) if a release only consists of bug fixes, documentation or i18n
   fixes, raise the patch level

2) if a release has new features (minor and major), which do not break
   network or automate compatibility (i.e. no raise in the major
   automate version number), but which might require a database upgrade
   or the regeneration of the cache, raise the minor level

3) if a major flag day introduces network incompatibility, or the
   automate interface has been changed in an incompatible way, or
   anything worse happened, raise the major level


While I'm going to manage the upcoming 0.99 and 1.0.0 releases, I'd like
to give my release manager hat to somebody else afterwards, so I can
concentrate on other things a bit more. I'm not out of the world, so
whoever wants to take the job can of course count on my help.

Doing releases does not involve much - the process is fairly good
documented. Perhaps the most important skills are a bit of a passion for
the software and some accuracy :)

So, who's up for the job?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature