Re: 2.7.2 for the New Year?

I went with my instinct about the +. Not on the tagged version, then 
added in the next change. But maybe the next change should be to a2+, if 
+ means "approaching" rather than "beyond".

I found one reference for the CPython convention (possibly a Subversion 
convention): 
http://effbot.org/pyfaq/how-does-the-python-version-numbering-scheme-work.htm, 
but it's gone from the modern FAQ.

What we should be doing is laid out in 
https://www.python.org/dev/peps/pep-0440/, which has a lot to say about 
releases of anything in the PyPI ecosystem, but nothing about 
non-releases. We comply in the sense that 2.7.2a1 is a compliant version 
identifier.

2.7.2a1+ violates PEP 440, so it does not identify a release, which in a 
sense is what we wanted to say.

Jeff Allen

On 22/11/2017 22:17, [email protected] wrote:
> Hi Jeff,
>
> That looks right except (as you where guessing) jython.version should be:
>
> <property name="jython.version" value="2.7.2a1+"/>
>
> The plus is a convention copied from CPython that I'm pretty sure
> means that this is still in development and is not the tagged 2.7.2a1.
> The reason we have a "noplus" version if I'm remembering correctly is
> that the + doesn't work as part of a name for the maven packages.
>
> As for tagging:
>
> I think I'm the only one with the permissions on maven to actually
> push a package, though I'm happy to share the responsibility :) -- let
> me know and I will look into how you get those rights if you want
> them. I think anyone can tag a release, but it probably makes sense
> for the person who pushes the release to be the same as the one who
> tags it.
>
> Thanks for moving this forward!
>
> -Frank
>
> On Wed, Nov 22, 2017 at 1:08 PM, Jeff Allen <[email protected]> wrote:
>> Thanks Frank. 2nd or 27th Feb, perhaps.
>>
>> As you're the expert in this, can I ask am I doing this right (in build.xml,
>> obviously):
>>
>>          <!-- The current version info -->
>>          <property name="jython.version" value="2.7.2a1"/>
>>          <property name="jython.version.noplus" value="2.7.2a1"/>
>>          <property name="jython.major_version" value="2"/>
>>          <property name="jython.minor_version" value="7"/>
>>          <property name="jython.micro_version" value="2"/>
>>          <property name="jython.release_level"
>> value="${PY_RELEASE_LEVEL_ALPHA}"/>
>>          <property name="jython.release_serial" value="1"/>
>>
>> In history, I see we commit this type of change, then there's a commit with
>> a tag. Am I able to push a change that adds a tag? ISTR there's a
>> restriction.
>>
>> When do we add the + to a version? (We seem to have forgotten so far in
>> 2.7.1.) Does the plus have a magical effect somewhere?
>>
>> Jeff
>>
>> Jeff Allen
>>
>> On 22/11/2017 19:42, [email protected] wrote:
>>
>> A new year's 2.7.2 with a limited scope is definitely a great idea, as
>> is an updated GitHub based website. I'm on board!
>>
>> -Frank
>>
>> On Tue, Nov 21, 2017 at 3:32 PM, Jeff Allen <[email protected]> wrote:
>>
>> All:
>>
>> How about it? This seems like a reasonable interval since 2.7.1.
>>
>> Frank/Jim: would you care to set a goal? What else ought we to have in that
>> release?
>>
>> I think we should mean by the answer, what we'd like to see in 2.7.2b1. Then
>> we only take on fixes during beta we didn't foresee or can't avoid. That
>> way, we hopefully don't stay in beta very long. I'm extrapolating a bit from
>> https://github.com/jython/devguide/blob/jython/devcycle.rst#stages (cloned
>> from CPython) but it seems a good discipline to prevent late de-stabilising
>> change.
>>
>> Is it perhaps as important to create a revised web site to back the release?
>> (We have talked about a site we can all contribute to via GitHub.)
>>
>> Also, I've been meaning to ask, the current dev tip should identify as
>> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as soon
>> as we decide we're having a 2.7.2? I think I see how this works in
>> build.xml.
>>
>> Jeff
>>
>> --
>> Jeff Allen
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Jython-dev mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev