Niclas, I wanted to read through your notes pretty in depth before responding.
On Thu, Jan 5, 2017 at 7:37 PM Niclas Hedhman <nic...@hedhman.org> wrote: > Coming late to the party... > > This has been discussed, and contentious, since "forever". A long time ago, > there was a notion that a podling release was not an ASF release (which was > the main reason for the "incubating" marker in all release and support > artifacts. But that pendulum has swung in the opposite direction, and > podling releases are now expected to be at ASF TLP levels. > > Thank you for acknowledging this. > Pierre pointed out that "incubating" refers to community and not code, but > we don't release a community, we release code. I think this is an important > fact. > > So, instead of tying the "incubating" marker to "incubating", I would favor > a system of marker(s) indicating the code maturity (incl legal). So, for a > podling release to be 1.2.3 (a la Groovy), the same release standard as > TLPs are applied, but allow "alpha", "rc" or similar markers for podlings > to "practice" releases. Probably not pushing those to mirrors, but > otherwise identical in "process" for podling to get their grips on the > release process. > I think this is a fair point, and probably close to what podling communities do (when its a fairly new codebase). We often see releases in the 0.x line, and in the 1+ lines. Its up to the podling to determine how mature they are from a release numbering standpoint. I wouldn't want the IPMC to enforce a versioning scheme. It does however seem like a foundation wide versioning scheme may make sense, or at least references to common references, e.g. semver, may make sense as a recommendation to new podlings. > > So, I am +1 with John's "something is broken" observation, although I also > agree with the many "-1"s that think there is value to the public here. > > > Cheers > > On Wed, Jan 4, 2017 at 7:47 PM, John D. Ament <johndam...@apache.org> > wrote: > > > I'll point out that this is a cancel thread..., I'm fine if people want > to > > continue chatting in here, but I started a new discussion on > > https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0f > > d0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E > > > > I'll try to answer questions I saw pop up > > > > Mark Struberg: No, ignoring commons/log4j for a minute, other projects > > continue to work under legacy maven coordinates. Includes one i already > > linked to - groovy, also freemarker, zest/polygene (a project that went > > straight to TLP). There's neither foundation policy nor legal impact by > > using other very similar marks, especially when the project's name hasn't > > changed. Publishing under "com.oracle.someProduct" would probably be bad > > from a marks standpoint since it shows as property of some other company, > > whereas former foundations or completely independent projects. Plus, the > > way maven central works you own the entire tld, except for cases where > its > > a known third party publisher. For instance, I own (personally) the > domain > > name ament.ws and have access to publish under maven coordinates > > ws.ament.*. Github users have to request io.github.themselves > manually. I > > assume that something similar exists between the ASF and Sonatype to > enable > > publishing under org.apache, and ensure that no one else can use > > org.apache. > > > > Pierre Smits: This is something I expected to be a hot topic. So while > > 100% consensus isn't expected, a clear path forward is something to > expect, > > even if not everyone is happy about the outcome. FWIW, there seem to be > 3 > > different POVs (that I could identify) on those who were against the > idea: > > > > - Those who thought this was dropping -incubating from the Apache release > > archive. > > - Those who acknowledged that this was maven specific and felt it should > > continue as is. > > - Those who acknowledged that this was currently maven specific and > should > > be made broader. > > > > John > > > > > > On Wed, Jan 4, 2017 at 4:49 AM Martijn Dashorst < > > martijn.dasho...@gmail.com> > > wrote: > > > > > Late to the party, but having a long think about this is sometimes > > > beneficial. > > > > > > +1 to drop the -incubator/-incubating version attachment for any > > > artifacts (not just Maven). > > > > > > My reasoning is the following: > > > > > > Source code lives longer than any community. Long after a podling has > > > gone through the incubator, the code remains. The releases remain. How > > > a community conducts itself doesn't reflect on the released code. Code > > > just exists. > > > > > > While it is important for current users coming to a project to know > > > the status of the community, does it really matter if the code is in > > > incubation or has graduated? Does that matter in 5 years whether the > > > code of foo-1.2 was incubating while the community has graduated and > > > now resides in the attic? > > > > > > Releases have a long life. Code has a long life. We shouldn't mix > > > timely things like project status with long lived things like > > > releases. Websites are examples of timely, short lived documents and > > > incubation status is a (relatively) short lived state in the long > > > lives of projects. We shouldn't burden the long lived artifacts with > > > the orthogonal status of a project. > > > > > > Martijn > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 2, 2017 at 6:22 PM, John D. Ament <johndam...@apache.org> > > > wrote: > > > > All, > > > > > > > > I'm calling to vote on a proposed policy change. Current guide at > [1] > > > > indicates that maven artifacts should include incubator (or > incubating) > > > in > > > > the version string of maven artifacts. Its labeled as a best > practice, > > > not > > > > a requirement and is not a policy followed on other repository > > management > > > > tools (e.g. PyPi). > > > > > > > > I therefore push forward that the incubator will cease expecting > > > java-based > > > > projects to publish artifacts with "-incubating" in the version > string, > > > > with the understanding that: > > > > > > > > - Incubating is a term used to refer to a project's stability, not a > > > > release's stability. It is generally understood that incubating > > projects > > > > are not necessarily immature, but may have a potential of failing to > > > become > > > > a TLP. > > > > - Podling releases are endorsed, the podling itself is not endorsed. > > We > > > > will not approve releases that are blatantly against ASF policies. > > > > > > > > > > > > [ ] +1 Drop the -incubator/-incubating expectation of maven projects > > > > [ ] +/0 > > > > [ ] -1 Don't drop because.... > > > > > > > > > > > > [1]: > > > > http://incubator.apache.org/guides/release-java.html#best- > > practice-maven > > > > > > > > > > > > -- > > > Become a Wicket expert, learn from the best: http://wicketinaction.com > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > -- > Niclas Hedhman, Software Developer > http://polygene.apache.org <http://zest.apache.org> - New Energy for Java >
