[Cryptography-dev] Release Cadences

[Donald Stufft]

On Apr 21, 2014, at 2:43 PM, Jarret Raim <jarret.raim at RACKSPACE.COM> wrote:

> +1 with what Donald said for me.
> 
> Jarret
> 
> From: Donald Stufft <donald at stufft.io>
> Reply-To: "cryptography-dev at python.org" <cryptography-dev at python.org>
> Date: Monday, April 21, 2014 at 1:37 PM
> To: "cryptography-dev at python.org" <cryptography-dev at python.org>
> Subject: Re: [Cryptography-dev] Release Cadences
> 
>> 
>> On Apr 21, 2014, at 2:31 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
>> 
>>> Now that we’re an upstream dependency for at least one major project (PyOpenSSL) it might make sense to try to fall into a monthly release cadence. This way we wouldn't block important features in our bindings from being consumed by downstream and we’ll also be able to get features out more regularly in hazmat/recipes.
>>> 
>>> This would be helpful right now in allowing JP to schedule releases of PyOpenSSL that contain dependencies on new features we add. It would also help prevent situations like issue 941 (https://github.com/pyca/cryptography/issues/941) from arising in the future.
>>> 
>>> If we did want to do monthly release cadence then next Monday would be essentially a month from the release of 0.3. We would need to significantly triage our fourth release issue list (and get some reviews!), but that will always be true for any release.
>>> 
>>> Do people generally support this idea?
>>> 
>>> -Paul
>>> _______________________________________________
>>> Cryptography-dev mailing list
>>> Cryptography-dev at python.org
>>> https://mail.python.org/mailman/listinfo/cryptography-dev
>> 
>> 
>> 
>> I think while we're still young, with new features being added at a high pace
>> that a monthly release cycle makes sense. I think we'll want to make sure that
>> this process is as automated as we can make it in order to reasonably achieve
>> that. Probably in the future we'll want to lengthen our release cadence but
>> that's a discussion for another day.
>> 
>> I do think that if we essentially say every X we'll issue a new release then
>> having release milestones don't really make a lot of sense though. If we're
>> doing time based releases then what gets released is whatever has landed by
>> the time the next release rolls around.
>> 
>> -----------------
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>> 
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev


More thoughts!

If we're going to move to a real time based release schedule then perhaps we
want to look at changing our version scheme? Right now we're doing a fairly
standard X.Y.Z (although at the moment it's mostly 0.X.Y). I think that
probably we're not going to follow semver and thus there's not a lot of point
to having a Major.Minor.Patch version scheme like that.

Probably we should just move to YY.N where YY is the last two digits of the
year (so this should allow us to version our project sanely until 2100 at which
point it's someone else's problem!). The N would just be a monotonically
increasing integer that represents the Nth release in that year. so we'd have
14.1, 14.2, 14.3, .., 14.N.

The only reason I see for wanting to keep using the Major.Minor.Patch release
semantics is if we want to leave it open to release a breaking API change
and be able to communicate that to our users. However I think that we probably
don't want to do that? Even if we are we probably don't want to still be using
0.x since people are using this in production now and 0.x is no longer
relevant.

One additional thought is that maybe we want to make it YY.N.Y where Y is
almost always 0 except in the case that we want to release a security patch for
an older version. This isn't strictly requires as the tooling will make
YY.N == YY.N.0 however I think if we're likely to ever release a patch like
that it's cleaner to always have the same number of digits in our version.

One more additional thought stemming from the above, what is our support
policy, especially with a high cadence release like monthly? Do we require
people to update to the latest to get bug fixes? Security Fixes? Do we backport
bug fixes or security fixes? If we do backport how far back to do we backport?

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140421/840d07ce/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20140421/840d07ce/attachment-0001.sig>