From: Jeff A. <ja...@fa...> - 2017-11-26 19:17:09
|
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, fwi...@gm... 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 <ja...@fa...> 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, fwi...@gm... 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 <ja...@fa...> 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 >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> >> |