[DISCUSS] Release process changes

["John D. Ament" <jo...@apache.org>]

Hey guys

While cutting the 1.5.4 release, there were a few snaf-u's I noticed.
Nothing crazy, but wanted to put this out there to see if it makes sense.

- the contents of RELEASING.md should be on the website.  the root readme
should point to it.
- Update RELEASING.md with the vote template.
- Change the release process to have a single parameter for release
version, and have the release plugin use that value for tag and next
version.
- Either we should push changes or not push changes.  Making that
consistent will reduce questions.  I went with push changes.
- The actual release command be a single line, instead of multiple.
- Point out that you have to close the nexus repo
- Update the website section to indicate what to do after checking it out.
- Put updating your key near the top.

John

Re: [DISCUSS] Release process changes

["John D. Ament" <jo...@apache.org>]

On Tue, Mar 7, 2017 at 10:38 PM Clebert Suconic <cl...@gmail.com>
wrote:

> On Tue, Mar 7, 2017 at 10:07 PM, John D. Ament <jo...@apache.org>
> wrote:
> > Hey guys
> >
> > While cutting the 1.5.4 release, there were a few snaf-u's I noticed.
> > Nothing crazy, but wanted to put this out there to see if it makes sense.
> >
> > - the contents of RELEASING.md should be on the website.  the root readme
> > should point to it.
> > - Update RELEASING.md with the vote template.
> > - Change the release process to have a single parameter for release
> > version, and have the release plugin use that value for tag and next
> > version.
> > - Either we should push changes or not push changes.  Making that
> > consistent will reduce questions.  I went with push changes.
>
> I had once made a mistake (operation error), and had to re-cut the
> release. making a double push on the repo...
> I thought it would be better to push manually.
>
>
Not pushing is what many projects do.  I have no personal preference, and
simply executed line by line, only realizing the missing piece after I had
pushed (and wondering why I was being prompted).  Many projects will do a
github fork with the tag indicating that this will be pushed to the main
repo upon successful vote.

Personally, when the project hits a stable level, and the release is fully
automated, the chances of a problem occurring with the release shrink and
the likelihood of error drops.  Its a group decision, if people feel
comfortable pushing to the main repo on a release, they should continue
on.  We can always do release branches and merge that release branch into
the source branch when done, another common approach. Fewer repos required.


>
> > - The actual release command be a single line, instead of multiple.
>
>
You can chain mvn release:prepare release:perform in a single step, without
needing two different executions.  This would have eliminated one local
build.




>
> > - Point out that you have to close the nexus repo
> > - Update the website section to indicate what to do after checking it
> out.
>
> I'm not sure what you mean? or how we would do it with a single line?
>

Right now the website section says

### Web site update:

Make sure you get a copy of the website at:

```sh
svn co
https://svn.apache.org/repos/infra/websites/production/activemq/content/artemis/
```

And thats it.  I'm assuming I'm supposed to create a 1.5.4 directory, drop
files in there, and update
http://activemq.apache.org/artemis/docs.html manually
to indicate the new release.


>
> > - Put updating your key near the top.
>
>
> Everything else +1 beyond of my questions.
>
>
> >
> > John
>
>
>
> --
> Clebert Suconic
>

Re: [DISCUSS] Release process changes

[Clebert Suconic <cl...@gmail.com>]

On Tue, Mar 7, 2017 at 10:07 PM, John D. Ament <jo...@apache.org> wrote:
> Hey guys
>
> While cutting the 1.5.4 release, there were a few snaf-u's I noticed.
> Nothing crazy, but wanted to put this out there to see if it makes sense.
>
> - the contents of RELEASING.md should be on the website.  the root readme
> should point to it.
> - Update RELEASING.md with the vote template.
> - Change the release process to have a single parameter for release
> version, and have the release plugin use that value for tag and next
> version.
> - Either we should push changes or not push changes.  Making that
> consistent will reduce questions.  I went with push changes.

I had once made a mistake (operation error), and had to re-cut the
release. making a double push on the repo...
I thought it would be better to push manually.


> - The actual release command be a single line, instead of multiple.


> - Point out that you have to close the nexus repo
> - Update the website section to indicate what to do after checking it out.

I'm not sure what you mean? or how we would do it with a single line?

> - Put updating your key near the top.


Everything else +1 beyond of my questions.


>
> John



-- 
Clebert Suconic