about releases (was [PATCH] Update imaplib2 to 2.24)
nicolas.s-dev at laposte.net
Fri Jun 10 17:41:05 BST 2011
On Fri, Jun 10, 2011 at 01:50:18PM +0200, Sebastian Spaeth wrote:
> On Fri, 10 Jun 2011 00:38:02 +0200, Nicolas Sebrecht wrote:
> > The reasons why I won't do a dedicated release for this fix are:
> Understood. Yet, I think a fix to a bug that can potentially delete
> parts of your mail is something that we should treat as a critical
> change and that we (that is ... you... :-)) should at the very least put
> out an official call saying that the last release has this bug and that
> people are recommended to upgrade to current master (which contains only
> bugfixes) in order to fix this.
> Personally, I think we should tag master
> as 18.104.22.168 or so that people have a defined tag that we can recommend
> them to pull.
It would not be consistent. vA.B.C.D is currently used for the maint
branch. It means that if we want to start maint off of v6.3.3 one day,
we couldn't start at the expected v22.214.171.124.
> > 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 don't really care about the numbering scheme. All I can say is that I
> am a friend of frequent releases so that people and distros don't have
> an excuse to not be running the latest code. :-)
> How far in the release cycle are we?
Can't say. We don't use time-based release cycles. What I know is that
we are at v6.3.4-rc1 where previous cadidates gone until -rc3.
> I still have a few unsend branches
> that I could send now or hold back until after a release.
You could send them. This will let most people decide if it's welcome
now or should be pending.
More information about the OfflineIMAP-project