incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]
Date Sun, 08 Jan 2017 23:54:53 GMT
Yes, I think we all hear your "frustration" that the process is not as
streamlined as it perhaps could, nor that the documentation is as solid as
one might expect (patches are welcome)

The underlying "issue" between the previous "GitHub/Maven releases" and
"Apache releases" was discussed at length long time ago. Basically, pushing
something to Maven Central is not a release. It is a "convenience service"
by the project, and is not at all required from Apache's point of view.
This fact may have some repercussions in how you approach the release.

Perhaps it is possible to automate a bunch of this, for future podlings to
benefit from. And perhaps with help from someone who has experienced this
recently and have notes, infra could create a self-service portal for
setting it up.

In Apache Polygene, we have gotten very far in terms of release automation,
but the initial steps are of course outside our scope. Probably after our
next release, we will publish reusable Gradle components for the Apache
release process for other Gradle based projects to benefit from. We'll see
exactly how we do this.

Cheers
Niclas


On Mon, Jan 9, 2017 at 1:12 AM, Edward Capriolo <edlinuxguru@gmail.com>
wrote:

> On Sat, Jan 7, 2017 at 9:42 AM, John D. Ament <johndament@apache.org>
> wrote:
>
> > On Sat, Jan 7, 2017 at 9:23 AM Niclas Hedhman <niclas@hedhman.org>
> wrote:
> >
> > > On Sat, Jan 7, 2017 at 9:36 PM, John D. Ament <johndament@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.
>



-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message