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

[Sebastian Spaeth]

On Fri, 10 Jun 2011 00:38:02 +0200, Nicolas Sebrecht wrote:
> Feel free to send a new patch. ,-)

Will do. :)
 
> 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 6.3.3.1 or so that people have a defined tag that we can recommend
them to pull. But I am fine with not doing that.

> 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? I still have a few unsend branches
that I could send now or hold back until after a release.

  toSent/SSLcert_timevalidation
(make sure the SSL cert is not past its expiry date)

  toSent/flags_as_set
(treat mail flags as a set() object rather than a list to let us use set
arithmetics)

  toSent/rework-acquireconn
(some refactoring of an unwieldy long function)

  toSent/starttls
(still need to finish this one, implementing starttls support).

Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/offlineimap-project/attachments/20110610/c8a504f8/attachment-0001.sig>