On Sat, Jan 7, 2017 at 9:42 AM, John D. Ament <johndam...@apache.org> wrote:
> On Sat, Jan 7, 2017 at 9:23 AM Niclas Hedhman <nic...@hedhman.org> wrote: > > > On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament <johndam...@apache.org> > > wrote: > > > > > > 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. > > > > Yeah, this is a tricky question. On one hand I don't like to dictate, but > > as a user I like to have a unified view of the world. Perhaps one or two > > DOAP entries would be a good way, and more strongly promote the DOAP and > > over time our common tooling could provide the unified view. A bit of > "be a > > good citizen.... for your own sake" attitude. > > > > > I'm not sure what you mean by DOAP entries. Do you have an example? > > John > > > > > > > Cheers > > -- > > Niclas Hedhman, Software Developer > > http://polygene.apache.org - New Energy for Java > > > But that pendulum has swung in the opposite direction, and podling releases are now expected to be at ASF TLP levels. I agree with this. I have started the gossip podling. Getting the release out to ASF levels is a bit tricky. Let me explain my situation: For projects outside of apache I have my own github and I setup an account on sonatype. I publish two or three artifacts to maven central and have a good amount of foot traffic for what are niche projects. github, sonatype, and travis yaml is a lightning fast setup. Sonatype asks you to submit a jira one time and after that you can publish unlimited artifacts in your group to maven central. After the initial setup a single pom file is all you need to be publishing to maven central. mvn release clean; mvn release prepare; mvn release perform With some plugins you can even automate the closing and releasing the repository if you wish,I still do that by hand in sonatype UI. If you compare this with the apache process there are a lot of disconnected steps. For example, I took on the role of release engineer. We all live in the stack overflow generation, this document is really great https://www.apache.org/dev/release-signing.html in its detail, however it lacks the "here is the 10 steps you actually need" to cut a release. We also had to schedule a key signing party for me. Also it was very difficult to find the stripped down basic pom file. We luckily got a contributor that did 90% but as we got closer to the release I had to figure out how the rat plugin works, how to make it exclude things etc. <plugin> <groupId>org.apache.rat</groupId> <artifactId>apache-rat-plugin</artifactId> <configuration> <excludes> <exclude>README.md</exclude> <exclude>eclipse_template.xml</exclude> </excludes> </configuration> <executions> <execution> <phase>verify</phase> <goals> <goal>check</goal> </goals> </execution> </executions> </plugin> You have to go to a different page for the release module configuration <pushChanges>false</pushChanges> <localCheckout>true</localCheckout> <autoVersionSubmodules>true</autoVersionSubmodules> Now, I know this is just a process of tracking down some other pom file in the incubator and taking it apart. There were other things too like tickets to infra to give me assess to things svn, release.apache.org. At one point I was following some old doc in apache which confused me on which server to put my public_html file. Please do not take this to mean I am complaining about the current process or defending my own ignorance! However, if the process stays as it is. I do think one streamline doc could disconnect all the steps. An example would be like this. Checklist: Have a signed key with WEB of trust? NO - click here. Have svn access to path/to/keys ? Create infra ticket/contact podling Create INFRA for project jira Create INFRA for https://repository.apache.org/ Complete pom file with special release and rat baked in ... put your settings in .m2/settings file To wrap it up I do not mind the requirements put it was fairly daunting to connect u all the things that have to happen to make a release compared to (sonatype,git,travis) and I found the process tricky to navigate. It sapped more time than I would have liked and often you end up needing help from infra/ podling crew and people are not always free at the same time.
