Ran, One thing I was thinking of, we should include a step to clean up old releases. For instance, on dist/dev we should only have the release under vote. Once it's been approved we should be moving that to the dist/release. When we publish a new release on dist/release, the old release should be deleted.
John On Thu, Jul 13, 2017 at 6:58 AM Ran Ziv <r...@gigaspaces.com> wrote: > I've documented the release process on our Confluence: > https://cwiki.apache.org/confluence/display/ARIATOSCA/Release+Process > > This, together with the release automation script > <https://issues.apache.org/jira/browse/ARIA-307>, should hopefully make > things much simpler for the release manager of the next release. > > > Please let me know if you have any comments on the document or if you think > I might have missed something. > > > > On Mon, Jul 10, 2017 at 4:11 PM, Ran Ziv <r...@gigaspaces.com> wrote: > > > Done: > > https://issues.apache.org/jira/browse/ARIA-306 ( with sub-tasks > > https://issues.apache.org/jira/browse/ARIA-307 and > > https://issues.apache.org/jira/browse/ARIA-308 ) > > https://issues.apache.org/jira/browse/ARIA-309 > > > > > > On Mon, Jul 10, 2017 at 3:54 PM, John D. Ament <johndam...@apache.org> > > wrote: > > > >> Ran, > >> > >> Do you want to create JIRAs for these? > >> > >> John > >> > >> On Mon, Jul 10, 2017 at 8:13 AM Ran Ziv <r...@gigaspaces.com> wrote: > >> > >> > Thanks :) > >> > > >> > 1) Documenting the release process - I have it on my list and will get > >> it > >> > on our Confluence soon. I also wrote some scripts to ease this > process, > >> > we'll probably merge them onto the repo one way or another soon. > >> > 2) The sdist comes with generated HTML pages; We should probably have > >> these > >> > on our website as well. > >> > 3) One already exists on our confluence - here: > >> > https://cwiki.apache.org/confluence/display/ARIATOSCA/Contri > >> buting+to+ARIA > >> > and here: > >> > > https://cwiki.apache.org/confluence/display/ARIATOSCA/Contributing+Code > >> > 4) Making things easily discoverable - IMO that's mostly website work, > >> need > >> > to make sure the website links everywhere needed including our > >> Confluence > >> > etc.. > >> > 5) Downloads page - yup, more website work :) > >> > > >> > > >> > Thanks for the tips, I hope we'll be able to follow up on those > shortly. > >> > > >> > > >> > > >> > On Mon, Jul 10, 2017 at 1:04 AM, Suneel Marthi < > suneel.mar...@gmail.com > >> > > >> > wrote: > >> > > >> > > Same here, congrats Team on first release. > >> > > > >> > > On Sun, Jul 9, 2017 at 5:20 PM, John D. Ament < > johndam...@apache.org> > >> > > wrote: > >> > > > >> > > > All, > >> > > > > >> > > > I wanted to express my well wishes to you all on a successful > first > >> > > > release. Most podlings see this as a milestone, I'll be updating > >> the > >> > > > various tracking sheets shortly with this note. > >> > > > > >> > > > So what's next? Once the mechanics of a release are squared away, > >> > > projects > >> > > > figure out ways to grow the community. Here's a short list of > >> things > >> > I'd > >> > > > recommend: > >> > > > > >> > > > - Make sure the release process is documented and that the next > >> release > >> > > has > >> > > > a different release manager. > >> > > > - Start putting together developer centric documentation. This > may > >> > > include > >> > > > some high level architecture, written designs. > >> > > > - Put together a contributor's guide. This may explain how the > >> project > >> > > > works (via github pull requests), creating JIRA tickets, browsing > >> > > fisheye, > >> > > > testing locally. > >> > > > - Make all of this easily discoverable. We have a lot of these > >> > > documents, > >> > > > but they may be hard to find. > >> > > > - Make sure we have a downloads page that points to the source > >> release > >> > > (ASF > >> > > > requirement). > >> > > > > >> > > > John > >> > > > > >> > > > >> > > >> > > > > >
