Release procedure next steps

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Release procedure next steps

Benson Margulies
Someone else has expressed interest in pushing along the RM string for
the plugin, here what need to be done.

1: log into repository.apache.org using Apache committer credentials.
2: click on staging repositories
3: select my 'test' version stage for the plugin and then click on drop.

...

4. Ensure that your ~/.m2/settings.xml has:

a: under servers, an entry like:

  <server>
            <id>repository.apache.org</id>
            <username>you</username>
            <password>your apache password</password>
        </server>

b: under profiles, an entry like:

      <profile>
            <id>signed_release</id>
            <properties>
                <gpg.passphrase>your passphrase</gpg.passphrase>
                <gpg.keyname>your key name</gpg.keyname>
            </properties>
        </profile>

4: in develop or the branch of your choice,

  mvn release:prepare -Psigned_release

When asked for a version, say, '0.0.1', and accept defaults for tag
and next dev version.

5: mvn release:perform

6: send out vote email

7: if the branch you picked wasn't 'develop', merge to develop.

8: decide what to do about 'master'.

9: update website to talk about the settings.xml stuff.

10: eagerly await feedback and 72-hour clock.
Reply | Threaded
Open this post in threaded view
|

Re: Release procedure next steps

Joe Witt
Benson,

Awesome thanks.  I was able to make a staging repo of 'orgapachenifi-0002'
and the signed release with all the artifacts appears to have gone well.

I will attempt to do a similar test with the full build so that it goes to
staging.  If all goes well then I'll do the nar-maven-plugin release as
0.0.1 and proceed with the remainder of the steps you outline.  This does
seem pretty simple right now so either I'm missing something or this is
much nicer than I feared it would be.

Thanks
Joe

On Fri, Jan 16, 2015 at 11:45 AM, Benson Margulies <[hidden email]>
wrote:

> Someone else has expressed interest in pushing along the RM string for
> the plugin, here what need to be done.
>
> 1: log into repository.apache.org using Apache committer credentials.
> 2: click on staging repositories
> 3: select my 'test' version stage for the plugin and then click on drop.
>
> ...
>
> 4. Ensure that your ~/.m2/settings.xml has:
>
> a: under servers, an entry like:
>
>   <server>
>             <id>repository.apache.org</id>
>             <username>you</username>
>             <password>your apache password</password>
>         </server>
>
> b: under profiles, an entry like:
>
>       <profile>
>             <id>signed_release</id>
>             <properties>
>                 <gpg.passphrase>your passphrase</gpg.passphrase>
>                 <gpg.keyname>your key name</gpg.keyname>
>             </properties>
>         </profile>
>
> 4: in develop or the branch of your choice,
>
>   mvn release:prepare -Psigned_release
>
> When asked for a version, say, '0.0.1', and accept defaults for tag
> and next dev version.
>
> 5: mvn release:perform
>
> 6: send out vote email
>
> 7: if the branch you picked wasn't 'develop', merge to develop.
>
> 8: decide what to do about 'master'.
>
> 9: update website to talk about the settings.xml stuff.
>
> 10: eagerly await feedback and 72-hour clock.
>
Reply | Threaded
Open this post in threaded view
|

Re: Release procedure next steps

Joe Witt
Regarding step 8 for master i propose we simply do the following after each
tag gets generated:

The next two commands assume the tag created was something like
'nar-maven-plugin-0.0.1-incubating'

git checkout master
git merge nar-maven-plugin-0.0.1-incubating

This approach of course means the whole source tree is being merged but the
key is that the specific state of the source tree is as it was at the time
the release occurred.  This seems reasonable.

* Looking into the structure of the vote email
* Looking into updating the website to talk about the settings.xml and to
document our release process

Once we get through the nar-maven-plugin as a valid released item then we
can tackle the full build.  In the mean time we can do the version
switching needed like going from '0.0.1-SNAPSHOT' to
'0.0.1-incubating-SNAPSHOT'.

Thanks
Joe

On Fri, Jan 16, 2015 at 12:18 PM, Joe Witt <[hidden email]> wrote:

> Benson,
>
> Awesome thanks.  I was able to make a staging repo of 'orgapachenifi-0002'
> and the signed release with all the artifacts appears to have gone well.
>
> I will attempt to do a similar test with the full build so that it goes to
> staging.  If all goes well then I'll do the nar-maven-plugin release as
> 0.0.1 and proceed with the remainder of the steps you outline.  This does
> seem pretty simple right now so either I'm missing something or this is
> much nicer than I feared it would be.
>
> Thanks
> Joe
>
> On Fri, Jan 16, 2015 at 11:45 AM, Benson Margulies <[hidden email]>
> wrote:
>
>> Someone else has expressed interest in pushing along the RM string for
>> the plugin, here what need to be done.
>>
>> 1: log into repository.apache.org using Apache committer credentials.
>> 2: click on staging repositories
>> 3: select my 'test' version stage for the plugin and then click on drop.
>>
>> ...
>>
>> 4. Ensure that your ~/.m2/settings.xml has:
>>
>> a: under servers, an entry like:
>>
>>   <server>
>>             <id>repository.apache.org</id>
>>             <username>you</username>
>>             <password>your apache password</password>
>>         </server>
>>
>> b: under profiles, an entry like:
>>
>>       <profile>
>>             <id>signed_release</id>
>>             <properties>
>>                 <gpg.passphrase>your passphrase</gpg.passphrase>
>>                 <gpg.keyname>your key name</gpg.keyname>
>>             </properties>
>>         </profile>
>>
>> 4: in develop or the branch of your choice,
>>
>>   mvn release:prepare -Psigned_release
>>
>> When asked for a version, say, '0.0.1', and accept defaults for tag
>> and next dev version.
>>
>> 5: mvn release:perform
>>
>> 6: send out vote email
>>
>> 7: if the branch you picked wasn't 'develop', merge to develop.
>>
>> 8: decide what to do about 'master'.
>>
>> 9: update website to talk about the settings.xml stuff.
>>
>> 10: eagerly await feedback and 72-hour clock.
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Release procedure next steps

Mike Drob-2
In reply to this post by Benson Margulies
Thanks for writing this up!

On Fri, Jan 16, 2015 at 8:45 AM, Benson Margulies <[hidden email]>
wrote:

> Someone else has expressed interest in pushing along the RM string for
> the plugin, here what need to be done.
>
> 1: log into repository.apache.org using Apache committer credentials.
> 2: click on staging repositories
> 3: select my 'test' version stage for the plugin and then click on drop.
>
> ...
>
> 4. Ensure that your ~/.m2/settings.xml has:
>
> a: under servers, an entry like:
>
>   <server>
>             <id>repository.apache.org</id>
>             <username>you</username>
>             <password>your apache password</password>
>         </server>
>
> b: under profiles, an entry like:
>
>       <profile>
>             <id>signed_release</id>
>             <properties>
>                 <gpg.passphrase>your passphrase</gpg.passphrase>
>                 <gpg.keyname>your key name</gpg.keyname>
>             </properties>
>         </profile>
>
> For those of us extra-concerned about password security,
http://maven.apache.org/guides/mini/guide-encryption.html provides info
about additional protection.


> 4: in develop or the branch of your choice,
>
>   mvn release:prepare -Psigned_release
>
> When asked for a version, say, '0.0.1', and accept defaults for tag
> and next dev version.
>
> 5: mvn release:perform
>
> 6: send out vote email
>
> 7: if the branch you picked wasn't 'develop', merge to develop.
>
> 8: decide what to do about 'master'.
>
> 9: update website to talk about the settings.xml stuff.
>
> 10: eagerly await feedback and 72-hour clock.
>
Reply | Threaded
Open this post in threaded view
|

Re: Release procedure next steps

Joe Witt
In reply to this post by Joe Witt
Things noticed so far:

1) The NOTICE must be updated to reflect the proper copyright year
2) The LICENSE, NOTICE, DISCLAIMER from our top level of the source
directory doesn't end up in the source-release tar.gz.  We get a stock
NOTICE and LICENSE file and no DISCLAIMER at all.  These were accounted for
properly in the binary convenience builds but not sure how to have them
come into the source builds as-is.

Plan [unless someone comes up with a better idea]
- Fix the Copyright year on the notice
- Move the LICENSE, DISCLAIMER, and NOTICE files down to the release-able
project level.  IE: Put a copy of them in 'nifi' and a copy of them in
'nar-maven-plugin'.
- Update the LICENSE file in nar-maven-plugin and NOTICE file in
'nar-maven-plugin' as needed.
- redo release:prepare release:perform

I am planning to kill the nar-maven-plugin-0.0.1-incubating tag we have in
Git, rollback the version, and to remove the staging build in nexus until
we get a solution in place for these items.

Still think we can avoid having an additional git repo but perhaps we are
just swimming too upstream now.  Could just request another repo
'incubator-nifi-maven.git'.

Thanks
Joe

On Fri, Jan 16, 2015 at 12:54 PM, Joe Witt <[hidden email]> wrote:

> Regarding step 8 for master i propose we simply do the following after
> each tag gets generated:
>
> The next two commands assume the tag created was something like
> 'nar-maven-plugin-0.0.1-incubating'
>
> git checkout master
> git merge nar-maven-plugin-0.0.1-incubating
>
> This approach of course means the whole source tree is being merged but
> the key is that the specific state of the source tree is as it was at the
> time the release occurred.  This seems reasonable.
>
> * Looking into the structure of the vote email
> * Looking into updating the website to talk about the settings.xml and to
> document our release process
>
> Once we get through the nar-maven-plugin as a valid released item then we
> can tackle the full build.  In the mean time we can do the version
> switching needed like going from '0.0.1-SNAPSHOT' to
> '0.0.1-incubating-SNAPSHOT'.
>
> Thanks
> Joe
>
> On Fri, Jan 16, 2015 at 12:18 PM, Joe Witt <[hidden email]> wrote:
>
>> Benson,
>>
>> Awesome thanks.  I was able to make a staging repo of
>> 'orgapachenifi-0002' and the signed release with all the artifacts appears
>> to have gone well.
>>
>> I will attempt to do a similar test with the full build so that it goes
>> to staging.  If all goes well then I'll do the nar-maven-plugin release as
>> 0.0.1 and proceed with the remainder of the steps you outline.  This does
>> seem pretty simple right now so either I'm missing something or this is
>> much nicer than I feared it would be.
>>
>> Thanks
>> Joe
>>
>> On Fri, Jan 16, 2015 at 11:45 AM, Benson Margulies <[hidden email]
>> > wrote:
>>
>>> Someone else has expressed interest in pushing along the RM string for
>>> the plugin, here what need to be done.
>>>
>>> 1: log into repository.apache.org using Apache committer credentials.
>>> 2: click on staging repositories
>>> 3: select my 'test' version stage for the plugin and then click on drop.
>>>
>>> ...
>>>
>>> 4. Ensure that your ~/.m2/settings.xml has:
>>>
>>> a: under servers, an entry like:
>>>
>>>   <server>
>>>             <id>repository.apache.org</id>
>>>             <username>you</username>
>>>             <password>your apache password</password>
>>>         </server>
>>>
>>> b: under profiles, an entry like:
>>>
>>>       <profile>
>>>             <id>signed_release</id>
>>>             <properties>
>>>                 <gpg.passphrase>your passphrase</gpg.passphrase>
>>>                 <gpg.keyname>your key name</gpg.keyname>
>>>             </properties>
>>>         </profile>
>>>
>>> 4: in develop or the branch of your choice,
>>>
>>>   mvn release:prepare -Psigned_release
>>>
>>> When asked for a version, say, '0.0.1', and accept defaults for tag
>>> and next dev version.
>>>
>>> 5: mvn release:perform
>>>
>>> 6: send out vote email
>>>
>>> 7: if the branch you picked wasn't 'develop', merge to develop.
>>>
>>> 8: decide what to do about 'master'.
>>>
>>> 9: update website to talk about the settings.xml stuff.
>>>
>>> 10: eagerly await feedback and 72-hour clock.
>>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Release procedure next steps

Benson Margulies
On Fri, Jan 16, 2015 at 4:33 PM, Joe Witt <[hidden email]> wrote:
> Things noticed so far:
>
> 1) The NOTICE must be updated to reflect the proper copyright year
> 2) The LICENSE, NOTICE, DISCLAIMER from our top level of the source
> directory doesn't end up in the source-release tar.gz.  We get a stock
> NOTICE and LICENSE file and no DISCLAIMER at all.  These were accounted for
> properly in the binary convenience builds but not sure how to have them
> come into the source builds as-is.

Well, we probably could script copying them into the nar-maven-plugin
dir. Failing that, we need to examine the stock assembly descriptor
and see it is configurable; otherwise we need to copy it and fix the
pathnames it picks up.

>
> Plan [unless someone comes up with a better idea]
> - Fix the Copyright year on the notice
> - Move the LICENSE, DISCLAIMER, and NOTICE files down to the release-able
> project level.  IE: Put a copy of them in 'nifi' and a copy of them in
> 'nar-maven-plugin'.
> - Update the LICENSE file in nar-maven-plugin and NOTICE file in
> 'nar-maven-plugin' as needed.
> - redo release:prepare release:perform
>
> I am planning to kill the nar-maven-plugin-0.0.1-incubating tag we have in
> Git, rollback the version, and to remove the staging build in nexus until
> we get a solution in place for these items.
>
> Still think we can avoid having an additional git repo but perhaps we are
> just swimming too upstream now.  Could just request another repo
> 'incubator-nifi-maven.git'.
>
> Thanks
> Joe
>
> On Fri, Jan 16, 2015 at 12:54 PM, Joe Witt <[hidden email]> wrote:
>
>> Regarding step 8 for master i propose we simply do the following after
>> each tag gets generated:
>>
>> The next two commands assume the tag created was something like
>> 'nar-maven-plugin-0.0.1-incubating'
>>
>> git checkout master
>> git merge nar-maven-plugin-0.0.1-incubating
>>
>> This approach of course means the whole source tree is being merged but
>> the key is that the specific state of the source tree is as it was at the
>> time the release occurred.  This seems reasonable.
>>
>> * Looking into the structure of the vote email
>> * Looking into updating the website to talk about the settings.xml and to
>> document our release process
>>
>> Once we get through the nar-maven-plugin as a valid released item then we
>> can tackle the full build.  In the mean time we can do the version
>> switching needed like going from '0.0.1-SNAPSHOT' to
>> '0.0.1-incubating-SNAPSHOT'.
>>
>> Thanks
>> Joe
>>
>> On Fri, Jan 16, 2015 at 12:18 PM, Joe Witt <[hidden email]> wrote:
>>
>>> Benson,
>>>
>>> Awesome thanks.  I was able to make a staging repo of
>>> 'orgapachenifi-0002' and the signed release with all the artifacts appears
>>> to have gone well.
>>>
>>> I will attempt to do a similar test with the full build so that it goes
>>> to staging.  If all goes well then I'll do the nar-maven-plugin release as
>>> 0.0.1 and proceed with the remainder of the steps you outline.  This does
>>> seem pretty simple right now so either I'm missing something or this is
>>> much nicer than I feared it would be.
>>>
>>> Thanks
>>> Joe
>>>
>>> On Fri, Jan 16, 2015 at 11:45 AM, Benson Margulies <[hidden email]
>>> > wrote:
>>>
>>>> Someone else has expressed interest in pushing along the RM string for
>>>> the plugin, here what need to be done.
>>>>
>>>> 1: log into repository.apache.org using Apache committer credentials.
>>>> 2: click on staging repositories
>>>> 3: select my 'test' version stage for the plugin and then click on drop.
>>>>
>>>> ...
>>>>
>>>> 4. Ensure that your ~/.m2/settings.xml has:
>>>>
>>>> a: under servers, an entry like:
>>>>
>>>>   <server>
>>>>             <id>repository.apache.org</id>
>>>>             <username>you</username>
>>>>             <password>your apache password</password>
>>>>         </server>
>>>>
>>>> b: under profiles, an entry like:
>>>>
>>>>       <profile>
>>>>             <id>signed_release</id>
>>>>             <properties>
>>>>                 <gpg.passphrase>your passphrase</gpg.passphrase>
>>>>                 <gpg.keyname>your key name</gpg.keyname>
>>>>             </properties>
>>>>         </profile>
>>>>
>>>> 4: in develop or the branch of your choice,
>>>>
>>>>   mvn release:prepare -Psigned_release
>>>>
>>>> When asked for a version, say, '0.0.1', and accept defaults for tag
>>>> and next dev version.
>>>>
>>>> 5: mvn release:perform
>>>>
>>>> 6: send out vote email
>>>>
>>>> 7: if the branch you picked wasn't 'develop', merge to develop.
>>>>
>>>> 8: decide what to do about 'master'.
>>>>
>>>> 9: update website to talk about the settings.xml stuff.
>>>>
>>>> 10: eagerly await feedback and 72-hour clock.
>>>>
>>>
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Release procedure next steps

Joe Witt
Went on an Erlich-esque vision quest to see about eliminating the
nar-maven-plugin altogether using the maven-assembly-plugin.  Allow me to
summarize the findings:

FAIL.

With that learning opportunity behind me:

Went ahead and restructured the top level directory to split the two
releases more clearly.  Put appropriate versions of the
notice/license/disclaimer in each.  The 'nar-maven-plugin' doesn't need the
same license/notice as its pure ASF v2.  So this is probably for the best.
The releases will be rooted properly then and have the necessary legal
artifacts.  As it stands now the top level of our source tree in Git does
*not* have the LICENSE/NOTICE/DISCLAIMER.  But it does have a simple readme
explaining the two projects.  I believe this is correct (unless someone
knows of policy saying those have to be in the git repo at the top level).
I know there is a policy for releases/release artifacts and I think we're
good on that front.  The only real downside of this approach i can see now
is that the tags for each release will cover the full repo which goes
beyond the single artifact tree being released.

I've also gone ahead and cleared out the execute script bundle.  It was
basically a dangling entity and turns out it had what was at least
questionable licensing dependencies.  It is probably useful and is worth
someone bringing back in at some time should those licensing issues be
sorted.

Cleaned up the NOTICE copyright years.  Updated all dependencies that the
very awesome mvn versions plugin identified as eligible for updating.

Finally updated the nifi side of the house to have all versions indicate
0.0.1-incubating-SNAPSHOT.

This is all committed and sitting on branch "NIFI-270-2".  Request a
review/attempt to do the full build/feedback.

Thanks
Joe

On Fri, Jan 16, 2015 at 4:41 PM, Benson Margulies <[hidden email]>
wrote:

> On Fri, Jan 16, 2015 at 4:33 PM, Joe Witt <[hidden email]> wrote:
> > Things noticed so far:
> >
> > 1) The NOTICE must be updated to reflect the proper copyright year
> > 2) The LICENSE, NOTICE, DISCLAIMER from our top level of the source
> > directory doesn't end up in the source-release tar.gz.  We get a stock
> > NOTICE and LICENSE file and no DISCLAIMER at all.  These were accounted
> for
> > properly in the binary convenience builds but not sure how to have them
> > come into the source builds as-is.
>
> Well, we probably could script copying them into the nar-maven-plugin
> dir. Failing that, we need to examine the stock assembly descriptor
> and see it is configurable; otherwise we need to copy it and fix the
> pathnames it picks up.
>
> >
> > Plan [unless someone comes up with a better idea]
> > - Fix the Copyright year on the notice
> > - Move the LICENSE, DISCLAIMER, and NOTICE files down to the release-able
> > project level.  IE: Put a copy of them in 'nifi' and a copy of them in
> > 'nar-maven-plugin'.
> > - Update the LICENSE file in nar-maven-plugin and NOTICE file in
> > 'nar-maven-plugin' as needed.
> > - redo release:prepare release:perform
> >
> > I am planning to kill the nar-maven-plugin-0.0.1-incubating tag we have
> in
> > Git, rollback the version, and to remove the staging build in nexus until
> > we get a solution in place for these items.
> >
> > Still think we can avoid having an additional git repo but perhaps we are
> > just swimming too upstream now.  Could just request another repo
> > 'incubator-nifi-maven.git'.
> >
> > Thanks
> > Joe
> >
> > On Fri, Jan 16, 2015 at 12:54 PM, Joe Witt <[hidden email]> wrote:
> >
> >> Regarding step 8 for master i propose we simply do the following after
> >> each tag gets generated:
> >>
> >> The next two commands assume the tag created was something like
> >> 'nar-maven-plugin-0.0.1-incubating'
> >>
> >> git checkout master
> >> git merge nar-maven-plugin-0.0.1-incubating
> >>
> >> This approach of course means the whole source tree is being merged but
> >> the key is that the specific state of the source tree is as it was at
> the
> >> time the release occurred.  This seems reasonable.
> >>
> >> * Looking into the structure of the vote email
> >> * Looking into updating the website to talk about the settings.xml and
> to
> >> document our release process
> >>
> >> Once we get through the nar-maven-plugin as a valid released item then
> we
> >> can tackle the full build.  In the mean time we can do the version
> >> switching needed like going from '0.0.1-SNAPSHOT' to
> >> '0.0.1-incubating-SNAPSHOT'.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Fri, Jan 16, 2015 at 12:18 PM, Joe Witt <[hidden email]> wrote:
> >>
> >>> Benson,
> >>>
> >>> Awesome thanks.  I was able to make a staging repo of
> >>> 'orgapachenifi-0002' and the signed release with all the artifacts
> appears
> >>> to have gone well.
> >>>
> >>> I will attempt to do a similar test with the full build so that it goes
> >>> to staging.  If all goes well then I'll do the nar-maven-plugin
> release as
> >>> 0.0.1 and proceed with the remainder of the steps you outline.  This
> does
> >>> seem pretty simple right now so either I'm missing something or this is
> >>> much nicer than I feared it would be.
> >>>
> >>> Thanks
> >>> Joe
> >>>
> >>> On Fri, Jan 16, 2015 at 11:45 AM, Benson Margulies <
> [hidden email]
> >>> > wrote:
> >>>
> >>>> Someone else has expressed interest in pushing along the RM string for
> >>>> the plugin, here what need to be done.
> >>>>
> >>>> 1: log into repository.apache.org using Apache committer credentials.
> >>>> 2: click on staging repositories
> >>>> 3: select my 'test' version stage for the plugin and then click on
> drop.
> >>>>
> >>>> ...
> >>>>
> >>>> 4. Ensure that your ~/.m2/settings.xml has:
> >>>>
> >>>> a: under servers, an entry like:
> >>>>
> >>>>   <server>
> >>>>             <id>repository.apache.org</id>
> >>>>             <username>you</username>
> >>>>             <password>your apache password</password>
> >>>>         </server>
> >>>>
> >>>> b: under profiles, an entry like:
> >>>>
> >>>>       <profile>
> >>>>             <id>signed_release</id>
> >>>>             <properties>
> >>>>                 <gpg.passphrase>your passphrase</gpg.passphrase>
> >>>>                 <gpg.keyname>your key name</gpg.keyname>
> >>>>             </properties>
> >>>>         </profile>
> >>>>
> >>>> 4: in develop or the branch of your choice,
> >>>>
> >>>>   mvn release:prepare -Psigned_release
> >>>>
> >>>> When asked for a version, say, '0.0.1', and accept defaults for tag
> >>>> and next dev version.
> >>>>
> >>>> 5: mvn release:perform
> >>>>
> >>>> 6: send out vote email
> >>>>
> >>>> 7: if the branch you picked wasn't 'develop', merge to develop.
> >>>>
> >>>> 8: decide what to do about 'master'.
> >>>>
> >>>> 9: update website to talk about the settings.xml stuff.
> >>>>
> >>>> 10: eagerly await feedback and 72-hour clock.
> >>>>
> >>>
> >>>
> >>
>