[TIP] 1.0.0 for unittest2?

[Michael Foord]

On 17/11/14 20:56, Robert Collins wrote:
> On 18 November 2014 06:36, Michael Foord <michael at voidspace.org.uk> wrote:
>> On 30/10/14 09:30, Robert Collins wrote:
>>> Anyone have specific criteria we should meet before bumping unittest2
>>> to 1.0.0 (which I'd like to do to get it onto a semver path).
>>
>> For the record, I have no opinion on this. I vaguely wonder if we should
>> adopt Python release numbers instead and track the "upstream" releases
>> instead of ad-hoc releases.
>>
>> Possibly with a micro version number of our own if we need to fix bugs that
>> are unittest2 specific?
> I too had pondered on that.
>
> Here's the broad situation:
>
>   - my intent is to aggressively backport on changes to tip, not on
> releases of cPython - that way we have a) some backpressure *against*
> spurious API breaks in cPython and b) early feedback if we do
> something daft :) and c) as little disincentive for fixing things in
> the right place as possible.
This seems like a killer argument to not *only* tracking releases.

>   - we're going to have a problem with versions before cPython does
> each major release. E.g. right now we'd be what? 3.5.0.4?
That seems ok to me if we go down that road.

>   -  our current version numbers are strictly lower than cPython's, so
> we can adopt cPython's versions easily if we want, modulo the concern
> above (and assuming we're happy with 4-element versions).
Postponing the decision - and maybe hitting 1.0.0 with the release of 
CPython 3.5 if we decide not to track CPython version numbers is fine 
with me.

Tracking CPython version numbers (with the additional micro-micro 
version) does make it easy to tell what version of Python you have 
feature parity with (so which docs to read!). So it's an attractive option.

Michael

> -Rob
>