about releases (was [PATCH] Update imaplib2 to 2.24)

[Nicolas Sebrecht]

On Thu, Jun 09, 2011 at 11:24:10PM +0200, Sebastian Spaeth wrote:
> On Thu, 9 Jun 2011 19:08:38 +0200, Nicolas Sebrecht wrote:

> > Applied against master and next.

> I forgot to update our Changelog in this commit,

Feel free to send a new patch. ,-)

>                                                  but IMHO we should put out a
> new release with this fix ASAP and warn people to upgraded, so that
> distros can get a fixed version without danger of data loss.

People and distros wanting the fix can fetch it from current next or
master branch. I do apply important fixes to master to let others
benefit of these patches ASAP. It is expected that master can have
important fixes without official release. The master content is not
supposed to be released without merging the whole next at that time.

On the other side, next still stands for the content going to be
released and will live his next-branch life as usual, knowing that
master content can contain unreleased and important fixes.

The reasons why I won't do a dedicated release for this fix are:

  - a fix may include more important breakage than what it pretends to
    solve;
  - other stuff was merged since previous release and could have
    serious breakages, too.

Bugs are everywhere and in place since the time the related code was
written. We live with them until someone get them fixed.

If you think it worth, I could do an official call asking to people
touched by this issue to upgrade to current master.

We could change usual conventions, of course. But it would look very odd
in the middle of a candidate cycle. So, no I won't do that now.


That beeing said, I have in mind for some time to start a new major
release (aka v6.4.0).  Given that our current workflow and release
cycles are very far from what used John, it could be good time to review
the whole version conventions and expectations. I couldn't change that
before as it would have break too much things at the maintainer
migration time.

I'm open to any clue and constructive material. What about starting by
an official call for discussion about changes like that? I think it's
good time to do so (I mean far enough from both previous and next v6.3.4
stable).


-- 
Nicolas Sebrecht