Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

[Bruno P. Kinoshita]

Hi Rob!

Thanks for the instructions, and for writing them so well and quickly!

Removed everything from the imaging's dist area first as you suggested. Then 
had a look at the new docs, and also at commons-text's pom.xml. Updated 
imaging's pom.xml.

Then produced the local artifacts first, and everything looked OK. Then used 
the next step to produce the staging repository. (did that a few times; first 
time dropping a release and re-rolling a new one...)

And it's amazing! It uploaded everything, with no errors, avoided uploading the 
.tar.gz and .zip files (sooo annoying) and also created the dist area.

Then closed the repository in the staging repo.

## Notes:

- The docs about the vote e-mail generation say target/vote.txt... copying and 
trying to do a `vim /target/vote.txt` failed, and then I realized it's actually 
`target/VOTE.txt` (nit-picking!)

- Also, the e-mail generated contained:

"We have fixed quite a few bugs and added some significant enhancements since 
Apache Commons Imaging 1.5"

I mistakenly left the bc.version to 1.5, but just replaced the occurrences of 
1.5 by 0.97-incubator, and mentioned that clirr was to be ignored as this was 
the first release of this new component (i.e. imaging != sanselan). Hopefully 
that's OK.

- I forgot to tag RC2, so it failed with

The Git tag commons-imaging-1.0-alpha1-RC2 commit for this RC is fatal: 
ambiguous argument 'commons-imaging-1.0-alpha1-RC2': unknown revision or path 
not in the working tree.

I proceeded to tag the current release with `git tag -s 
commons-imaging-1.0-alpha1-RC2`, and updated the text. My bad, don't think we 
need to update the docs for that.

- Maven artifacts URL had a variable that was not expanded? Maybe I missed 
something in my pom.xml?

 
https://repository.apache.org/content/repositories/orgapachecommons-${commons.nexus.repo.id}/org/apache/commons/commons-imaging/1.0-alpha1/

Fixed the link to point to 
https://repository.apache.org/content/repositories/orgapachecommons-1395/org/apache/commons/commons-imaging/1.0-alpha1/

--

As this is my first release with this new plugin, and since I manually edited 
more than what's expected in the vote.txt, plus forgot the tag... it's likely I 
missed/messed something, so may roll one more release soon if necessary (plenty 
of time this weekend).

Vote e-mail sent, have a look if I followed the instructions correctly.

Thank you again!!
Bruno

ps: Will look for the Slack link again... I don't have Slack on this 
computer... do you know if we have the link for the slack channel somewhere in 
the website/twitter/etc?







From: Rob Tompkins 
To: Bruno P. Kinoshita  
Cc: Commons Developers List 
Sent: Tuesday, 30 October 2018 1:33 AM
Subject: Re: [site] update release process (Was: Re: [VOTE] Release Commons 
Imaging 1.0-alpha1 based on RC1)





> On Oct 29, 2018, at 7:24 AM, Rob Tompkins  wrote:
> 
> 
> 
>> On Oct 28, 2018, at 8:04 PM, Bruno P. Kinoshita  wrote:
>> 
>> Will cancel the vote tonight, thanks for spotting that @Gary.
>> 
>> @Rob, thanks a lot for all the great work on the new plugin. I might be able 
>> to roll a new RC tonight, or during this week. Would you have a pointer to 
>> the some page with the commands I have to run to properly use the plugin and 
>> upload the right binaries and signatures, please?
>> 
>> Not in a hurry to cut the release, so if you are planning to write the docs 
>> this week, I'd be happy to review/try them for the imaging RC2.
> 
> I’ll try to work on this this morning (UTC-4) both on the [site] as well as 
> sending the details over to you.

Hey Bruno,

Since you’re using [parent] version 47, you should be most the way there. I, on 
the preparing releases page, added the needed configurations: 

http://commons.apache.org/releases/prepare.html#Configure_the_Build_and_Release_Plugin_to_Generate_a_Complete_Set_of_Release_Artifacts

>From there you should simply be able to run

mvn -Duser.name= -Prelease -Ptest-deploy clean test package 
site deploy

to test the deployment (test SVN dist commit ends up in 
./target/commons-release-plugin/scm), and

mvn -Duser.name= -Prelease clean test package site deploy

to run the deployment (assuming that your settings.xml has sufficient 
privileges). Note, this is also covered here: 

http://commons.apache.org/releases/prepare.html#Create_the_Release_Candidate_with_the_Commons_Release_Plugin.

IMPORTANT: to get the svn distribution commit to properly work, make sure that 
https://dist.apache.org/repos/dist/dev/commons/imaging/ is completely empty.

Feel free to ping me on slack if anything arises. I do know that we’re 14 hours 
different in terms of timezones though.

Cheers,

-Rob

> 
> -Rob
> 
>> 
>> 
>> 
>> Thanks heaps
>> Bruno
>> 
>> 
&g

Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

[Rob Tompkins]

> On Oct 29, 2018, at 7:24 AM, Rob Tompkins  wrote:
> 
> 
> 
>> On Oct 28, 2018, at 8:04 PM, Bruno P. Kinoshita  wrote:
>> 
>> Will cancel the vote tonight, thanks for spotting that @Gary.
>> 
>> @Rob, thanks a lot for all the great work on the new plugin. I might be able 
>> to roll a new RC tonight, or during this week. Would you have a pointer to 
>> the some page with the commands I have to run to properly use the plugin and 
>> upload the right binaries and signatures, please?
>> 
>> Not in a hurry to cut the release, so if you are planning to write the docs 
>> this week, I'd be happy to review/try them for the imaging RC2.
> 
> I’ll try to work on this this morning (UTC-4) both on the [site] as well as 
> sending the details over to you.

Hey Bruno,

Since you’re using [parent] version 47, you should be most the way there. I, on 
the preparing releases page, added the needed configurations: 

http://commons.apache.org/releases/prepare.html#Configure_the_Build_and_Release_Plugin_to_Generate_a_Complete_Set_of_Release_Artifacts

From there you should simply be able to run

mvn -Duser.name= -Prelease -Ptest-deploy clean test package 
site deploy

to test the deployment (test SVN dist commit ends up in 
./target/commons-release-plugin/scm), and

mvn -Duser.name= -Prelease clean test package site deploy

to run the deployment (assuming that your settings.xml has sufficient 
privileges). Note, this is also covered here: 

http://commons.apache.org/releases/prepare.html#Create_the_Release_Candidate_with_the_Commons_Release_Plugin.

IMPORTANT: to get the svn distribution commit to properly work, make sure that 
https://dist.apache.org/repos/dist/dev/commons/imaging/ is completely empty.

Feel free to ping me on slack if anything arises. I do know that we’re 14 hours 
different in terms of timezones though.

Cheers,
-Rob

> 
> -Rob
> 
>> 
>> 
>> 
>> Thanks heaps
>> Bruno
>> 
>> 
>> 
>> 
>> ________
>> From: Rob Tompkins 
>> To: Commons Developers List  
>> Cc: Bruno P. Kinoshita 
>> Sent: Monday, 29 October 2018 2:49 AM
>> Subject: [site] update release process (Was: Re: [VOTE] Release Commons 
>> Imaging 1.0-alpha1 based on RC1)
>> 
>> 
>> 
>> This is mildly on me for not updating the release docs recently. I’ll put 
>> that on my docket for the week. 
>> 
>> PS. @Bruno solid work and many thanks for rolling the RC.
>> 
>> Cheers,
>> -Rob
>> 
>> 
>>> On Oct 28, 2018, at 9:35 AM, Gary Gregory  wrote:
>>> 
>>> Hello Bruno,
>>> 
>>> Thank you for preparing the RC.
>>> 
>>> MD5 and SHA1 are no longer acceptable per Apache for our dist server.
>>> Please use SHA256 or SHA512. Our Commons release plugin will create those
>>> for you. Nexus has different requirements and that is fine for now.
>>> 
>>> Gary
>>> 
>>>> On Sun, Oct 28, 2018, 04:58 Bruno P. Kinoshita  wrote:
>>>> 
>>>> We have fixed quite a few bugs and added some significant enhancements
>>>> since Sanselan 0.97-incubator was released,
>>>> so I would like to release Apache Commons Imaging 1.0-alpha1.
>>>> 
>>>> This will be the first release after the project was renamed from Sanselan
>>>> to Apache Commons Imaging. This is an alpha
>>>> release candidate.
>>>> 
>>>> Apache Commons Imaging 1.0-alpha RC1 is available for review here:
>>>> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/
>>>> (svn revision 30460)
>>>> 
>>>> The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is
>>>> 44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here:
>>>> 
>>>> 
>>>> https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1
>>>> 
>>>> Maven artifacts are here:
>>>> https://repository.apache.org/content/repositories/orgapachecommons-1393/
>>>> 
>>>> These are the Maven artifacts and their hashes
>>>> 
>>>> commons-imaging-1.0-alpha1-javadoc.jar
>>>> (SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719)
>>>> commons-imaging-1.0-alpha1-sources.jar
>>>> (SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310)
>>>> commons-imaging-1.0-alpha1-test-sources.jar
>>>> (SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6)
>>>> commons-imaging-1.0-alpha1-tests.jar
>>>> (SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a03

Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

[Rob Tompkins]

> On Oct 28, 2018, at 8:04 PM, Bruno P. Kinoshita  wrote:
> 
> Will cancel the vote tonight, thanks for spotting that @Gary.
> 
> @Rob, thanks a lot for all the great work on the new plugin. I might be able 
> to roll a new RC tonight, or during this week. Would you have a pointer to 
> the some page with the commands I have to run to properly use the plugin and 
> upload the right binaries and signatures, please?
> 
> Not in a hurry to cut the release, so if you are planning to write the docs 
> this week, I'd be happy to review/try them for the imaging RC2.

I’ll try to work on this this morning (UTC-4) both on the [site] as well as 
sending the details over to you.

-Rob

> 
> 
> 
> Thanks heaps
> Bruno
> 
> 
> 
> 
> 
> From: Rob Tompkins 
> To: Commons Developers List  
> Cc: Bruno P. Kinoshita 
> Sent: Monday, 29 October 2018 2:49 AM
> Subject: [site] update release process (Was: Re: [VOTE] Release Commons 
> Imaging 1.0-alpha1 based on RC1)
> 
> 
> 
> This is mildly on me for not updating the release docs recently. I’ll put 
> that on my docket for the week. 
> 
> PS. @Bruno solid work and many thanks for rolling the RC.
> 
> Cheers,
> -Rob
> 
> 
>> On Oct 28, 2018, at 9:35 AM, Gary Gregory  wrote:
>> 
>> Hello Bruno,
>> 
>> Thank you for preparing the RC.
>> 
>> MD5 and SHA1 are no longer acceptable per Apache for our dist server.
>> Please use SHA256 or SHA512. Our Commons release plugin will create those
>> for you. Nexus has different requirements and that is fine for now.
>> 
>> Gary
>> 
>>> On Sun, Oct 28, 2018, 04:58 Bruno P. Kinoshita  wrote:
>>> 
>>> We have fixed quite a few bugs and added some significant enhancements
>>> since Sanselan 0.97-incubator was released,
>>> so I would like to release Apache Commons Imaging 1.0-alpha1.
>>> 
>>> This will be the first release after the project was renamed from Sanselan
>>> to Apache Commons Imaging. This is an alpha
>>> release candidate.
>>> 
>>> Apache Commons Imaging 1.0-alpha RC1 is available for review here:
>>> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/
>>> (svn revision 30460)
>>> 
>>> The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is
>>> 44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here:
>>> 
>>> 
>>> https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1
>>> 
>>> Maven artifacts are here:
>>> https://repository.apache.org/content/repositories/orgapachecommons-1393/
>>> 
>>> These are the Maven artifacts and their hashes
>>> 
>>> commons-imaging-1.0-alpha1-javadoc.jar
>>> (SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719)
>>> commons-imaging-1.0-alpha1-sources.jar
>>> (SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310)
>>> commons-imaging-1.0-alpha1-test-sources.jar
>>> (SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6)
>>> commons-imaging-1.0-alpha1-tests.jar
>>> (SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a0383326af)
>>> commons-imaging-1.0-alpha1.jar
>>> (SHA1: b39f13c05550327501224cd2cbd02591c59a8bbb)
>>> commons-imaging-1.0-alpha1.pom
>>> (SHA1: 03697c87b9e18b5c69946712c31c3fd85cdde1ee)
>>> 
>>> I have tested this with 8 using Maven 3.5.4 on Ubuntu LTS.
>>> 
>>> Details of changes for 1.0-alpha1 are in the release notes:
>>> 
>>> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/RELEASE-NOTES.txt
>>> 
>>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/changes-report.html
>>> 
>>> Site:
>>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/index.html
>>> (note some *relative* links are broken and the 1.2 directories are
>>> not yet created - these will be OK once the site is deployed)
>>> 
>>> RAT Report:
>>> 
>>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/rat-report.html
>>> 
>>> KEYS:
>>> https://www.apache.org/dist/commons/KEYS
>>> 
>>> Please review the release candidate and vote.
>>> This vote will close no sooner that 72 hours from now,
>>> i.e. sometime after 04:00 UTC 31-March 2010
>>> 
>>> [ ] +1 Release these artifacts
>>> [ ] +0 OK, but...
>>> [ ] -0 OK, but really should fix...
>>> [ ] -1 I oppose this release because...
>>> 
>>> Thanks!
>>> 
>>> Bruno
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

[Bruno P. Kinoshita]

Will cancel the vote tonight, thanks for spotting that @Gary.

@Rob, thanks a lot for all the great work on the new plugin. I might be able to 
roll a new RC tonight, or during this week. Would you have a pointer to the 
some page with the commands I have to run to properly use the plugin and upload 
the right binaries and signatures, please?

Not in a hurry to cut the release, so if you are planning to write the docs 
this week, I'd be happy to review/try them for the imaging RC2.



Thanks heaps
Bruno





From: Rob Tompkins 
To: Commons Developers List  
Cc: Bruno P. Kinoshita 
Sent: Monday, 29 October 2018 2:49 AM
Subject: [site] update release process (Was: Re: [VOTE] Release Commons Imaging 
1.0-alpha1 based on RC1)



This is mildly on me for not updating the release docs recently. I’ll put that 
on my docket for the week. 

PS. @Bruno solid work and many thanks for rolling the RC.

Cheers,
-Rob


> On Oct 28, 2018, at 9:35 AM, Gary Gregory  wrote:
> 
> Hello Bruno,
> 
> Thank you for preparing the RC.
> 
> MD5 and SHA1 are no longer acceptable per Apache for our dist server.
> Please use SHA256 or SHA512. Our Commons release plugin will create those
> for you. Nexus has different requirements and that is fine for now.
> 
> Gary
> 
>> On Sun, Oct 28, 2018, 04:58 Bruno P. Kinoshita  wrote:
>> 
>> We have fixed quite a few bugs and added some significant enhancements
>> since Sanselan 0.97-incubator was released,
>> so I would like to release Apache Commons Imaging 1.0-alpha1.
>> 
>> This will be the first release after the project was renamed from Sanselan
>> to Apache Commons Imaging. This is an alpha
>> release candidate.
>> 
>> Apache Commons Imaging 1.0-alpha RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/
>> (svn revision 30460)
>> 
>> The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is
>> 44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here:
>> 
>> 
>> https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1
>> 
>> Maven artifacts are here:
>> https://repository.apache.org/content/repositories/orgapachecommons-1393/
>> 
>> These are the Maven artifacts and their hashes
>> 
>> commons-imaging-1.0-alpha1-javadoc.jar
>> (SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719)
>> commons-imaging-1.0-alpha1-sources.jar
>> (SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310)
>> commons-imaging-1.0-alpha1-test-sources.jar
>> (SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6)
>> commons-imaging-1.0-alpha1-tests.jar
>> (SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a0383326af)
>> commons-imaging-1.0-alpha1.jar
>> (SHA1: b39f13c05550327501224cd2cbd02591c59a8bbb)
>> commons-imaging-1.0-alpha1.pom
>> (SHA1: 03697c87b9e18b5c69946712c31c3fd85cdde1ee)
>> 
>> I have tested this with 8 using Maven 3.5.4 on Ubuntu LTS.
>> 
>> Details of changes for 1.0-alpha1 are in the release notes:
>> 
>> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/RELEASE-NOTES.txt
>> 
>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/changes-report.html
>> 
>> Site:
>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/index.html
>> (note some *relative* links are broken and the 1.2 directories are
>> not yet created - these will be OK once the site is deployed)
>> 
>> RAT Report:
>> 
>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/rat-report.html
>> 
>> KEYS:
>> https://www.apache.org/dist/commons/KEYS
>> 
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now,
>> i.e. sometime after 04:00 UTC 31-March 2010
>> 
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>> 
>> Thanks!
>> 
>> Bruno
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[site] update release process (Was: Re: [VOTE] Release Commons Imaging 1.0-alpha1 based on RC1)

[Rob Tompkins]

This is mildly on me for not updating the release docs recently. I’ll put that 
on my docket for the week. 

PS. @Bruno solid work and many thanks for rolling the RC.

Cheers,
-Rob

> On Oct 28, 2018, at 9:35 AM, Gary Gregory  wrote:
> 
> Hello Bruno,
> 
> Thank you for preparing the RC.
> 
> MD5 and SHA1 are no longer acceptable per Apache for our dist server.
> Please use SHA256 or SHA512. Our Commons release plugin will create those
> for you. Nexus has different requirements and that is fine for now.
> 
> Gary
> 
>> On Sun, Oct 28, 2018, 04:58 Bruno P. Kinoshita  wrote:
>> 
>> We have fixed quite a few bugs and added some significant enhancements
>> since Sanselan 0.97-incubator was released,
>> so I would like to release Apache Commons Imaging 1.0-alpha1.
>> 
>> This will be the first release after the project was renamed from Sanselan
>> to Apache Commons Imaging. This is an alpha
>> release candidate.
>> 
>> Apache Commons Imaging 1.0-alpha RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/
>> (svn revision 30460)
>> 
>> The Git tag commons-imaging-1.0-alpha1-RC1 commit for this RC is
>> 44f4b12dc3f5131944a9c147e1a8f0dc18360806 which you can browse here:
>> 
>> 
>> https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC1
>> 
>> Maven artifacts are here:
>> https://repository.apache.org/content/repositories/orgapachecommons-1393/
>> 
>> These are the Maven artifacts and their hashes
>> 
>> commons-imaging-1.0-alpha1-javadoc.jar
>> (SHA1: 0f6c64af7dd7099024c5ecd9fd2632db04b1d719)
>> commons-imaging-1.0-alpha1-sources.jar
>> (SHA1: 12734288eca62bc87ac3b8efc77d66c80cd9a310)
>> commons-imaging-1.0-alpha1-test-sources.jar
>> (SHA1: 415cd0ff4af1c69d39b35c907ef29180ce4a03d6)
>> commons-imaging-1.0-alpha1-tests.jar
>> (SHA1: 9704b79c446e2a5b1f6c4ff7c09ac5a0383326af)
>> commons-imaging-1.0-alpha1.jar
>> (SHA1: b39f13c05550327501224cd2cbd02591c59a8bbb)
>> commons-imaging-1.0-alpha1.pom
>> (SHA1: 03697c87b9e18b5c69946712c31c3fd85cdde1ee)
>> 
>> I have tested this with 8 using Maven 3.5.4 on Ubuntu LTS.
>> 
>> Details of changes for 1.0-alpha1 are in the release notes:
>> 
>> https://dist.apache.org/repos/dist/dev/commons/imaging/IMAGING_1_0_RC1/RELEASE-NOTES.txt
>> 
>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/changes-report.html
>> 
>> Site:
>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/index.html
>> (note some *relative* links are broken and the 1.2 directories are
>> not yet created - these will be OK once the site is deployed)
>> 
>> RAT Report:
>> 
>> http://people.apache.org/~kinow/commons-imaging-1.0-alpha1-rc1/rat-report.html
>> 
>> KEYS:
>> https://www.apache.org/dist/commons/KEYS
>> 
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now,
>> i.e. sometime after 04:00 UTC 31-March 2010
>> 
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>> 
>> Thanks!
>> 
>> Bruno
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

[Oliver Heger]

Am 13.01.2018 um 15:36 schrieb Gilles:
> On Sat, 13 Jan 2018 08:48:19 -0500, Rob Tompkins wrote:
>> Given that right now we don’t have sufficient votes to release the
>> plugin, do folks want me to cancel this vote in leu of the lazy vote
>> process cleaning up the nits that folks have found? I’m curious since
>> folks don’t seem to have the appetite for this process.
> 
> ?
> 
> I don't think that anyone disagreed about "lazy" voting.
> So, you can do as you please.
> [IIUC, Gary is waiting for a release of the your new release
> plugin in order to attempt the release of a component.]

+1
Oliver

> 
> I surely am interested in the *idea* which I have about
> what you have been doing.  [I did not read a single line of
> the plugin code!  But I hope that it will solve the problem
> which I have exposed (about creating the distribution files
> for a modular project).

> 
> Regards,
> Gilles
> 
>>> On Jan 11, 2018, at 10:51 PM, Gary Gregory 
>>> wrote:
>>>
>>> Tangent: It just occurred to me that this could have helped in the
>>> process
>>> of developing this plugin:
>>> https://github.com/ok2c/httpcomponents-release-tools/wiki
>>>
>>> Gary
>>>
>>> On Thu, Jan 11, 2018 at 6:54 PM, Rob Tompkins 
>>> wrote:
>>>
 I had that quickly set up by adding

 ${dryRun}

 to the plugin configuration, but I admit  that’s a bit of a hack. I was
 just trying to be speedy in the first version of the plugin for folks’
 benefit.

> On Jan 11, 2018, at 7:25 PM, sebb  wrote:
>
>> On 11 January 2018 at 14:42, Rob Tompkins  wrote:
>> If you do try to run it locally make sure you add
>> true
>
> It would be useful to be able to define this on the command-line.
>
>> To the configuration section of the plugin.
>>
>>> On Jan 11, 2018, at 3:58 AM, Jörg Schaible <
 joerg.schai...@bpm-inspire.com> wrote:
>>>
>>> Am Wed, 10 Jan 2018 20:35:52 -0700 schrieb Gary Gregory:
>>>
 I wonder if:
 - This should be a LAZY VOTE since this is not an official
 component
 but
 rather a tool
>>>
>>> +1
>>>
 - We should release it as 1.0 anyway (unless obvious bugs
 are found) to avoid the chicken and egg problem: To really test
 this,
 I
 want to create an RC for Commons Collection (for example). But that
 means using a commons-release-plugin 1.0 version in my POM -
 which we
 cannot release as a repeatable build since 1.0 is not out yet. And
 cutting an RC with a 1.0-SNAPSHOT is not acceptable (not
 repeatable.)
>>>
>>> we might release 1.0-RC1 (or 0.1) as Sergio suggested.
>>>
>>> Cheers,
>>> Jörg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

[Gary Gregory]

I will find some time to review this weekend.

Gary

On Jan 13, 2018 6:48 AM, "Rob Tompkins"  wrote:

> Given that right now we don’t have sufficient votes to release the plugin,
> do folks want me to cancel this vote in leu of the lazy vote process
> cleaning up the nits that folks have found? I’m curious since folks don’t
> seem to have the appetite for this process.
>
> > On Jan 11, 2018, at 10:51 PM, Gary Gregory 
> wrote:
> >
> > Tangent: It just occurred to me that this could have helped in the
> process
> > of developing this plugin:
> > https://github.com/ok2c/httpcomponents-release-tools/wiki
> >
> > Gary
> >
> > On Thu, Jan 11, 2018 at 6:54 PM, Rob Tompkins 
> wrote:
> >
> >> I had that quickly set up by adding
> >>
> >> ${dryRun}
> >>
> >> to the plugin configuration, but I admit  that’s a bit of a hack. I was
> >> just trying to be speedy in the first version of the plugin for folks’
> >> benefit.
> >>
> >>> On Jan 11, 2018, at 7:25 PM, sebb  wrote:
> >>>
>  On 11 January 2018 at 14:42, Rob Tompkins  wrote:
>  If you do try to run it locally make sure you add
>  true
> >>>
> >>> It would be useful to be able to define this on the command-line.
> >>>
>  To the configuration section of the plugin.
> 
> > On Jan 11, 2018, at 3:58 AM, Jörg Schaible <
> >> joerg.schai...@bpm-inspire.com> wrote:
> >
> > Am Wed, 10 Jan 2018 20:35:52 -0700 schrieb Gary Gregory:
> >
> >> I wonder if:
> >> - This should be a LAZY VOTE since this is not an official component
> >> but
> >> rather a tool
> >
> > +1
> >
> >> - We should release it as 1.0 anyway (unless obvious bugs
> >> are found) to avoid the chicken and egg problem: To really test
> this,
> >> I
> >> want to create an RC for Commons Collection (for example). But that
> >> means using a commons-release-plugin 1.0 version in my POM - which
> we
> >> cannot release as a repeatable build since 1.0 is not out yet. And
> >> cutting an RC with a 1.0-SNAPSHOT is not acceptable (not
> repeatable.)
> >
> > we might release 1.0-RC1 (or 0.1) as Sergio suggested.
> >
> > Cheers,
> > Jörg
> >
> >
> > 
> -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
> 
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

[Gilles]

On Sat, 13 Jan 2018 08:48:19 -0500, Rob Tompkins wrote:

Given that right now we don’t have sufficient votes to release the
plugin, do folks want me to cancel this vote in leu of the lazy vote
process cleaning up the nits that folks have found? I’m curious since
folks don’t seem to have the appetite for this process.


?

I don't think that anyone disagreed about "lazy" voting.
So, you can do as you please.
[IIUC, Gary is waiting for a release of the your new release
plugin in order to attempt the release of a component.]

I surely am interested in the *idea* which I have about
what you have been doing.  [I did not read a single line of
the plugin code!  But I hope that it will solve the problem
which I have exposed (about creating the distribution files
for a modular project).]

Regards,
Gilles

On Jan 11, 2018, at 10:51 PM, Gary Gregory  
wrote:


Tangent: It just occurred to me that this could have helped in the 
process

of developing this plugin:
https://github.com/ok2c/httpcomponents-release-tools/wiki

Gary

On Thu, Jan 11, 2018 at 6:54 PM, Rob Tompkins  
wrote:



I had that quickly set up by adding

${dryRun}

to the plugin configuration, but I admit  that’s a bit of a hack. I 
was
just trying to be speedy in the first version of the plugin for 
folks’

benefit.


On Jan 11, 2018, at 7:25 PM, sebb  wrote:

On 11 January 2018 at 14:42, Rob Tompkins  
wrote:

If you do try to run it locally make sure you add
true


It would be useful to be able to define this on the command-line.


To the configuration section of the plugin.


On Jan 11, 2018, at 3:58 AM, Jörg Schaible <

joerg.schai...@bpm-inspire.com> wrote:


Am Wed, 10 Jan 2018 20:35:52 -0700 schrieb Gary Gregory:


I wonder if:
- This should be a LAZY VOTE since this is not an official 
component

but

rather a tool


+1


- We should release it as 1.0 anyway (unless obvious bugs
are found) to avoid the chicken and egg problem: To really test 
this,

I
want to create an RC for Commons Collection (for example). But 
that
means using a commons-release-plugin 1.0 version in my POM - 
which we
cannot release as a repeatable build since 1.0 is not out yet. 
And
cutting an RC with a 1.0-SNAPSHOT is not acceptable (not 
repeatable.)


we might release 1.0-RC1 (or 0.1) as Sergio suggested.

Cheers,
Jörg



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[release-plugin] release process (Was: Re: [VOTE] Release Commons Release Plugin 1.0 base on RC1)

[Rob Tompkins]

Given that right now we don’t have sufficient votes to release the plugin, do 
folks want me to cancel this vote in leu of the lazy vote process cleaning up 
the nits that folks have found? I’m curious since folks don’t seem to have the 
appetite for this process.

> On Jan 11, 2018, at 10:51 PM, Gary Gregory  wrote:
> 
> Tangent: It just occurred to me that this could have helped in the process
> of developing this plugin:
> https://github.com/ok2c/httpcomponents-release-tools/wiki
> 
> Gary
> 
> On Thu, Jan 11, 2018 at 6:54 PM, Rob Tompkins  wrote:
> 
>> I had that quickly set up by adding
>> 
>> ${dryRun}
>> 
>> to the plugin configuration, but I admit  that’s a bit of a hack. I was
>> just trying to be speedy in the first version of the plugin for folks’
>> benefit.
>> 
>>> On Jan 11, 2018, at 7:25 PM, sebb  wrote:
>>> 
 On 11 January 2018 at 14:42, Rob Tompkins  wrote:
 If you do try to run it locally make sure you add
 true
>>> 
>>> It would be useful to be able to define this on the command-line.
>>> 
 To the configuration section of the plugin.
 
> On Jan 11, 2018, at 3:58 AM, Jörg Schaible <
>> joerg.schai...@bpm-inspire.com> wrote:
> 
> Am Wed, 10 Jan 2018 20:35:52 -0700 schrieb Gary Gregory:
> 
>> I wonder if:
>> - This should be a LAZY VOTE since this is not an official component
>> but
>> rather a tool
> 
> +1
> 
>> - We should release it as 1.0 anyway (unless obvious bugs
>> are found) to avoid the chicken and egg problem: To really test this,
>> I
>> want to create an RC for Commons Collection (for example). But that
>> means using a commons-release-plugin 1.0 version in my POM - which we
>> cannot release as a repeatable build since 1.0 is not out yet. And
>> cutting an RC with a 1.0-SNAPSHOT is not acceptable (not repeatable.)
> 
> we might release 1.0-RC1 (or 0.1) as Sergio suggested.
> 
> Cheers,
> Jörg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Questions regarding improving the Apache Commons release process.

[Rob Tompkins]

I’ve found some success now using 
org.apache.maven.plugin-testing:maven-plugin-testing-harness:3.3.0. You may 
disregard the following questions.

Cheers,
-Rob

> On Jan 6, 2018, at 2:03 PM, Rob Tompkins  wrote:
> 
> Hello again Maven Team,
> 
> I’ve made substantive progress towards getting the commons team a release 
> plugin (https://github.com/chtompki/commons-release-plugin 
> <https://github.com/chtompki/commons-release-plugin>). However, in my attempt 
> at writing plugin unit tests for the first time, I’ve found myself running 
> into difficulties in dealing with which dependencies need to be in the 
> classpath to effectively run the maven-plugin-testing-harness. 
> 
> I was hoping to get another set of eyes on my work, namely the pom and the 
> unit test that is in flight (see the above repository), such that I can get 
> around these classpath issues and start writing proper tests for the plugin. 
> It is quite easy to see the issues that I’m having by cloning the project and 
> running “mvn test:"
> 
> Running org.apache.commons.release.plugin.mojos.CommonsSiteCompressionMojoTest
> Jan 06, 2018 2:00:13 PM org.eclipse.sisu.inject.Logs$JULSink warn
> WARNING: Error injecting: 
> org.apache.maven.artifact.resolver.DefaultArtifactResolver
> java.lang.NoClassDefFoundError: 
> Lorg/apache/maven/artifact/transform/ArtifactTransformationManager;
> at java.lang.Class.getDeclaredFields0(Native Method)
> at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
> at java.lang.Class.getDeclaredFields(Class.java:1916)
> 
> Any guidance here would be much welcomed, and moreover I can’t thank you guys 
> enough for the previous insights because they gave me the ability to make 
> solid progress on our release automation.
> 
> Many thanks and all the best,
> -Rob
> 
> 
>> On Dec 28, 2017, at 4:53 PM, Rob Tompkins > <mailto:chtom...@gmail.com>> wrote:
>> 
>> 
>> 
>>> On Dec 28, 2017, at 4:05 AM, Hervé BOUTEMY >> <mailto:herve.bout...@free.fr>> wrote:
>>> 
>>> Hi Rob,
>>> 
>>> one additional point: currently, for Maven itself, instead of adding new 
>>> Maven-specific ReleasePhase(s) to the default configuration, or configure 
>>> them in 
>>> our parent pom (I'm not sure documentation on how to do that is available: 
>>> I 
>>> could not find it), we chose first to create a separate "dist-tool" to 
>>> check 
>>> consistency of what is currently published in misc places and provide some 
>>> commands to fix when an inconsistency is found.
>>> 
>>> This happens through daily reports done by a Jenkins job [1]:
>>> - distribution area vs Maven Central [2] 
>>> - version from Maven site vs Maven Central [3]
>>> 
>>> We did not produce any release nor made it really configurable for 
>>> conventions 
>>> different from Maven ones (like Common's -src & -bin), but at least there 
>>> is a 
>>> configuration file to define artifacts to check [4]
>> 
>> Interesting. Thanks,.
>> 
>> -Rob
>> 
>>> 
>>> HTH
>>> 
>>> Hervé
>>> 
>>> 
>>> [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/ 
>>> <https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/>
>>> 
>>> [2] 
>>> https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/ 
>>> <https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/>
>>> dist-tool-check-source-release.html
>>> 
>>> [3] 
>>> https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/ 
>>> <https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/>
>>> dist-tool-check-index-page.html
>>> 
>>> [4] 
>>> https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/ 
>>> <https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/>
>>> dist-tool.conf.html
>>> 
>>> Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
>>>> Stephen,
>>>> 
>>>> I can’t thank you enough for your reply. I’ll take your suggestions and
>>>> continue to sandbox around using the maven-release-plugin as a guideline.
>>>> 
>>>> All the best and happy holidays,
>>>> -Rob
>>>> 
>>>>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly
>>>>> >>>> <mailto:stephen.alan.conno...@gmail.com>&

Re: Questions regarding improving the Apache Commons release process.

[Rob Tompkins]

Hello again Maven Team,

I’ve made substantive progress towards getting the commons team a release 
plugin (https://github.com/chtompki/commons-release-plugin 
<https://github.com/chtompki/commons-release-plugin>). However, in my attempt 
at writing plugin unit tests for the first time, I’ve found myself running into 
difficulties in dealing with which dependencies need to be in the classpath to 
effectively run the maven-plugin-testing-harness. 

I was hoping to get another set of eyes on my work, namely the pom and the unit 
test that is in flight (see the above repository), such that I can get around 
these classpath issues and start writing proper tests for the plugin. It is 
quite easy to see the issues that I’m having by cloning the project and running 
“mvn test:"

Running org.apache.commons.release.plugin.mojos.CommonsSiteCompressionMojoTest
Jan 06, 2018 2:00:13 PM org.eclipse.sisu.inject.Logs$JULSink warn
WARNING: Error injecting: 
org.apache.maven.artifact.resolver.DefaultArtifactResolver
java.lang.NoClassDefFoundError: 
Lorg/apache/maven/artifact/transform/ArtifactTransformationManager;
at java.lang.Class.getDeclaredFields0(Native Method)
at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
at java.lang.Class.getDeclaredFields(Class.java:1916)

Any guidance here would be much welcomed, and moreover I can’t thank you guys 
enough for the previous insights because they gave me the ability to make solid 
progress on our release automation.

Many thanks and all the best,
-Rob


> On Dec 28, 2017, at 4:53 PM, Rob Tompkins  wrote:
> 
> 
> 
>> On Dec 28, 2017, at 4:05 AM, Hervé BOUTEMY  wrote:
>> 
>> Hi Rob,
>> 
>> one additional point: currently, for Maven itself, instead of adding new 
>> Maven-specific ReleasePhase(s) to the default configuration, or configure 
>> them in 
>> our parent pom (I'm not sure documentation on how to do that is available: I 
>> could not find it), we chose first to create a separate "dist-tool" to check 
>> consistency of what is currently published in misc places and provide some 
>> commands to fix when an inconsistency is found.
>> 
>> This happens through daily reports done by a Jenkins job [1]:
>> - distribution area vs Maven Central [2] 
>> - version from Maven site vs Maven Central [3]
>> 
>> We did not produce any release nor made it really configurable for 
>> conventions 
>> different from Maven ones (like Common's -src & -bin), but at least there is 
>> a 
>> configuration file to define artifacts to check [4]
> 
> Interesting. Thanks,.
> 
> -Rob
> 
>> 
>> HTH
>> 
>> Hervé
>> 
>> 
>> [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/
>> 
>> [2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
>> dist-tool-check-source-release.html
>> 
>> [3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
>> dist-tool-check-index-page.html
>> 
>> [4] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
>> dist-tool.conf.html
>> 
>> Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
>>> Stephen,
>>> 
>>> I can’t thank you enough for your reply. I’ll take your suggestions and
>>> continue to sandbox around using the maven-release-plugin as a guideline.
>>> 
>>> All the best and happy holidays,
>>> -Rob
>>> 
>>>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly
>>>>  wrote:> 
>>>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins > <mailto:chtom...@apache.org>> wrote:
>>>>> Hello all,
>>>>> 
>>>>> Pardon, maybe this should have gone to your @user list, but why not ping
>>>>> the dev crew. I’ve been playing around the ideas surrounding our fairly
>>>>> manual release process for the components in Commons, and I was hoping
>>>>> for
>>>>> some insights.
>>>>> 
>>>>> Scripting the version changes isn’t really that big of a deal for us, and
>>>>> that I can manage. But, when it comes to publishing our artifacts to the
>>>>> apache nexus repository, and then separately publishing our -src and -bin
>>>>> assemblies to the dev dist subversion repository (and consequently
>>>>> deleting
>>>>> those artifacts from nexus as they’re “attached” for the purpose of gpg
>>>>> signing), I feel it a tad cumbersome.
>>>>> 
>>>>> I’ve fiddled around a little with the idea of detaching the -src and -bin

Re: [commons-release-plugin] Progress report. (Was: Re: Questions regarding improving the Apache Commons release process.)

[Gary Gregory]

Thank you for spearheading making our release process better.

One tricky thing to watch out for are components like Lang and DBCP which
have folder names on dist that are not the artifact ID. IOW lang vs lang3,
dbcp vs dbcp2.

Gary

On Dec 30, 2017 08:29, "Rob Tompkins"  wrote:

> Hello all,
>
> I just wanted to let everyone know where I’ve been running lately. I’m
> writing a new commons component specifically “commons-release-plugin” for
> the sake of making a maven plugin that adheres to our release process. I’m
> sandboxing it in my git work area:
>
> https://github.com/chtompki/commons-release-plugin <
> https://github.com/chtompki/commons-release-plugin>
>
> My goal is to get it functional an then bring it up for vote on creating
> it as a full fledged component (in the same vein as the
> commons-build-plugin).
>
> Currently, I have it declared locally in [text] with:
>
> org.apache.commons
> commons-release-plugin
> 0.1-SNAPSHOT
> 
>   scm:svn:https://dist.apache.org/repos/
> dist/dev/commons/text
> 
> 
>   
> detatch-assemblies
> verify
> 
>   detatch-assemblies
> 
>   
> 
>   
>
> immediately following this line: https://github.com/apache/
> commons-text/blob/master/pom.xml#L164 <https://github.com/apache/
> commons-text/blob/master/pom.xml#L164> in the pom. As it stands now, it
> detaches the distributions from the deployment to nexus (after gpg signing,
> and then copies them and the sha1’s and md5’s into a working directory in
> /target), My plan here is to use the maven-release-plugin as a guideline
> for how to publish these up to the dist svn repository. I think I’m further
> going to set up a mojo to do site deployment to somewhere (open to thoughts
> on where the site should go, maybe the dist svn area in a zip file like
> what Gary did with the latest [dbcp] release??).
>
> Given this is a progress report. I’m open to anyone telling me that I’m
> wasting my time and pointing me in a new direction.
>
> Cheers,
> -Rob
>
> P.S. I haven’t figured out how to write tests for maven plugins, so I have
> no testing in the project. I’m open to suggestions/help in that department
> if anyone wants to chip in and help.
>
>
> > On Dec 28, 2017, at 4:05 AM, Hervé BOUTEMY 
> wrote:
> >
> > Hi Rob,
> >
> > one additional point: currently, for Maven itself, instead of adding new
> > Maven-specific ReleasePhase(s) to the default configuration, or
> configure them in
> > our parent pom (I'm not sure documentation on how to do that is
> available: I
> > could not find it), we chose first to create a separate "dist-tool" to
> check
> > consistency of what is currently published in misc places and provide
> some
> > commands to fix when an inconsistency is found.
> >
> > This happens through daily reports done by a Jenkins job [1]:
> > - distribution area vs Maven Central [2]
> > - version from Maven site vs Maven Central [3]
> >
> > We did not produce any release nor made it really configurable for
> conventions
> > different from Maven ones (like Common's -src & -bin), but at least
> there is a
> > configuration file to define artifacts to check [4]
> >
> > HTH
> >
> > Hervé
> >
> >
> > [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/
> >
> > [2] https://builds.apache.org/view/M-R/view/Maven/job/dist-
> tool-plugin/site/
> > dist-tool-check-source-release.html
> >
> > [3] https://builds.apache.org/view/M-R/view/Maven/job/dist-
> tool-plugin/site/
> > dist-tool-check-index-page.html
> >
> > [4] https://builds.apache.org/view/M-R/view/Maven/job/dist-
> tool-plugin/site/
> > dist-tool.conf.html
> >
> > Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
> >> Stephen,
> >>
> >> I can’t thank you enough for your reply. I’ll take your suggestions and
> >> continue to sandbox around using the maven-release-plugin as a
> guideline.
> >>
> >> All the best and happy holidays,
> >> -Rob
> >>
> >>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly
> >>>  wrote:>
> >>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins  > <mailto:chtom...@apache.org>> wrote:
> >>>> Hello all,
> >>>>
> >>>> Pardon, maybe this should have gone to your @user list, but why not
> ping
> >>>> the dev crew. I’ve been playing around the

[commons-release-plugin] Progress report. (Was: Re: Questions regarding improving the Apache Commons release process.)

[Rob Tompkins]

Hello all,

I just wanted to let everyone know where I’ve been running lately. I’m writing 
a new commons component specifically “commons-release-plugin” for the sake of 
making a maven plugin that adheres to our release process. I’m sandboxing it in 
my git work area:

https://github.com/chtompki/commons-release-plugin 
<https://github.com/chtompki/commons-release-plugin>

My goal is to get it functional an then bring it up for vote on creating it as 
a full fledged component (in the same vein as the commons-build-plugin).

Currently, I have it declared locally in [text] with:

org.apache.commons
commons-release-plugin
0.1-SNAPSHOT

  
scm:svn:https://dist.apache.org/repos/dist/dev/commons/text


  
detatch-assemblies
verify

  detatch-assemblies

  

  

immediately following this line: 
https://github.com/apache/commons-text/blob/master/pom.xml#L164 
<https://github.com/apache/commons-text/blob/master/pom.xml#L164> in the pom. 
As it stands now, it detaches the distributions from the deployment to nexus 
(after gpg signing, and then copies them and the sha1’s and md5’s into a 
working directory in /target), My plan here is to use the maven-release-plugin 
as a guideline for how to publish these up to the dist svn repository. I think 
I’m further going to set up a mojo to do site deployment to somewhere (open to 
thoughts on where the site should go, maybe the dist svn area in a zip file 
like what Gary did with the latest [dbcp] release??).

Given this is a progress report. I’m open to anyone telling me that I’m wasting 
my time and pointing me in a new direction.

Cheers,
-Rob

P.S. I haven’t figured out how to write tests for maven plugins, so I have no 
testing in the project. I’m open to suggestions/help in that department if 
anyone wants to chip in and help.


> On Dec 28, 2017, at 4:05 AM, Hervé BOUTEMY  wrote:
> 
> Hi Rob,
> 
> one additional point: currently, for Maven itself, instead of adding new 
> Maven-specific ReleasePhase(s) to the default configuration, or configure 
> them in 
> our parent pom (I'm not sure documentation on how to do that is available: I 
> could not find it), we chose first to create a separate "dist-tool" to check 
> consistency of what is currently published in misc places and provide some 
> commands to fix when an inconsistency is found.
> 
> This happens through daily reports done by a Jenkins job [1]:
> - distribution area vs Maven Central [2] 
> - version from Maven site vs Maven Central [3]
> 
> We did not produce any release nor made it really configurable for 
> conventions 
> different from Maven ones (like Common's -src & -bin), but at least there is 
> a 
> configuration file to define artifacts to check [4]
> 
> HTH
> 
> Hervé
> 
> 
> [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/
> 
> [2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool-check-source-release.html
> 
> [3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool-check-index-page.html
> 
> [4] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool.conf.html
> 
> Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
>> Stephen,
>> 
>> I can’t thank you enough for your reply. I’ll take your suggestions and
>> continue to sandbox around using the maven-release-plugin as a guideline.
>> 
>> All the best and happy holidays,
>> -Rob
>> 
>>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly
>>>  wrote:> 
>>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins  <mailto:chtom...@apache.org>> wrote:
>>>> Hello all,
>>>> 
>>>> Pardon, maybe this should have gone to your @user list, but why not ping
>>>> the dev crew. I’ve been playing around the ideas surrounding our fairly
>>>> manual release process for the components in Commons, and I was hoping
>>>> for
>>>> some insights.
>>>> 
>>>> Scripting the version changes isn’t really that big of a deal for us, and
>>>> that I can manage. But, when it comes to publishing our artifacts to the
>>>> apache nexus repository, and then separately publishing our -src and -bin
>>>> assemblies to the dev dist subversion repository (and consequently
>>>> deleting
>>>> those artifacts from nexus as they’re “attached” for the purpose of gpg
>>>> signing), I feel it a tad cumbersome.
>>>> 
>>>> I’ve fiddled around a little with the idea of detaching the -src and -bin
>>

Re: Questions regarding improving the Apache Commons release process.

[Rob Tompkins]

> On Dec 28, 2017, at 4:05 AM, Hervé BOUTEMY  wrote:
> 
> Hi Rob,
> 
> one additional point: currently, for Maven itself, instead of adding new 
> Maven-specific ReleasePhase(s) to the default configuration, or configure 
> them in 
> our parent pom (I'm not sure documentation on how to do that is available: I 
> could not find it), we chose first to create a separate "dist-tool" to check 
> consistency of what is currently published in misc places and provide some 
> commands to fix when an inconsistency is found.
> 
> This happens through daily reports done by a Jenkins job [1]:
> - distribution area vs Maven Central [2] 
> - version from Maven site vs Maven Central [3]
> 
> We did not produce any release nor made it really configurable for 
> conventions 
> different from Maven ones (like Common's -src & -bin), but at least there is 
> a 
> configuration file to define artifacts to check [4]

Interesting. Thanks,.

-Rob

> 
> HTH
> 
> Hervé
> 
> 
> [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/
> 
> [2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool-check-source-release.html
> 
> [3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool-check-index-page.html
> 
> [4] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool.conf.html
> 
> Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
>> Stephen,
>> 
>> I can’t thank you enough for your reply. I’ll take your suggestions and
>> continue to sandbox around using the maven-release-plugin as a guideline.
>> 
>> All the best and happy holidays,
>> -Rob
>> 
>>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly
>>>  wrote:> 
>>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins  <mailto:chtom...@apache.org>> wrote:
>>>> Hello all,
>>>> 
>>>> Pardon, maybe this should have gone to your @user list, but why not ping
>>>> the dev crew. I’ve been playing around the ideas surrounding our fairly
>>>> manual release process for the components in Commons, and I was hoping
>>>> for
>>>> some insights.
>>>> 
>>>> Scripting the version changes isn’t really that big of a deal for us, and
>>>> that I can manage. But, when it comes to publishing our artifacts to the
>>>> apache nexus repository, and then separately publishing our -src and -bin
>>>> assemblies to the dev dist subversion repository (and consequently
>>>> deleting
>>>> those artifacts from nexus as they’re “attached” for the purpose of gpg
>>>> signing), I feel it a tad cumbersome.
>>>> 
>>>> I’ve fiddled around a little with the idea of detaching the -src and -bin
>>>> assemblies after gpg signing with some success, but then I have to delve
>>>> into the mechanics of publishing those up to the subversion repository,
>>>> and
>>>> clearly that problem has already been solved.
>>> 
>>> Is your problem you don’t want those going to Nexus staging but only to
>>> dist? Or is it that you want them *also* going to dist.
>>> 
>>> Personally... I see no reason to remove them from going to Nexus staging
>>> (in fact I have a background plan to add secondary signing support to
>>> staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
>>> though. That would mean that the PMC would be able to *add* their GPG
>>> signature to the staged artifacts as part of the voting... in which case
>>> you’d want to hold off uploading to dist until *after* the vote so you get
>>> the full set of signatures)
>>> 
>>> If you want to upload a subset of attached artifacts to dist as part of
>>> the
>>> release, that seems much more tenable... just a derivative of the
>>> scm-publish plugin from what I can see.
>>> 
>>> So I find myself in the space of trying to shoehorn our process into its
>>> 
>>>> the main maven-release-plugin, which I’ve found a tad difficult, versus
>>>> writing our own release plugin, which feels like I would be duplicating
>>>> tons of code (which I don’t want to do).
>>> 
>>> So the release plugin is really two parts:
>>> 
>>> 1. A toolkit for writing release plugins
>>> 
>>> 2. An example that does the job for the requirements of the Maven TLP and
>>> has seemed “sufficient” for a lot of other people.
>>> 
>>>

Re: Questions regarding improving the Apache Commons release process.

[Hervé BOUTEMY]

Hi Rob,

one additional point: currently, for Maven itself, instead of adding new 
Maven-specific ReleasePhase(s) to the default configuration, or configure them 
in 
our parent pom (I'm not sure documentation on how to do that is available: I 
could not find it), we chose first to create a separate "dist-tool" to check 
consistency of what is currently published in misc places and provide some 
commands to fix when an inconsistency is found.

This happens through daily reports done by a Jenkins job [1]:
- distribution area vs Maven Central [2] 
- version from Maven site vs Maven Central [3]

We did not produce any release nor made it really configurable for conventions 
different from Maven ones (like Common's -src & -bin), but at least there is a 
configuration file to define artifacts to check [4]

HTH

Hervé


[1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/

[2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool-check-source-release.html

[3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool-check-index-page.html

[4] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool.conf.html

Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
> Stephen,
> 
> I can’t thank you enough for your reply. I’ll take your suggestions and
> continue to sandbox around using the maven-release-plugin as a guideline.
> 
> All the best and happy holidays,
> -Rob
> 
> > On Dec 26, 2017, at 5:27 AM, Stephen Connolly
> >  wrote:> 
> > On Tue 26 Dec 2017 at 03:10, Rob Tompkins mailto:chtom...@apache.org>> wrote:
> >> Hello all,
> >> 
> >> Pardon, maybe this should have gone to your @user list, but why not ping
> >> the dev crew. I’ve been playing around the ideas surrounding our fairly
> >> manual release process for the components in Commons, and I was hoping
> >> for
> >> some insights.
> >> 
> >> Scripting the version changes isn’t really that big of a deal for us, and
> >> that I can manage. But, when it comes to publishing our artifacts to the
> >> apache nexus repository, and then separately publishing our -src and -bin
> >> assemblies to the dev dist subversion repository (and consequently
> >> deleting
> >> those artifacts from nexus as they’re “attached” for the purpose of gpg
> >> signing), I feel it a tad cumbersome.
> >> 
> >> I’ve fiddled around a little with the idea of detaching the -src and -bin
> >> assemblies after gpg signing with some success, but then I have to delve
> >> into the mechanics of publishing those up to the subversion repository,
> >> and
> >> clearly that problem has already been solved.
> > 
> > Is your problem you don’t want those going to Nexus staging but only to
> > dist? Or is it that you want them *also* going to dist.
> > 
> > Personally... I see no reason to remove them from going to Nexus staging
> > (in fact I have a background plan to add secondary signing support to
> > staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
> > though. That would mean that the PMC would be able to *add* their GPG
> > signature to the staged artifacts as part of the voting... in which case
> > you’d want to hold off uploading to dist until *after* the vote so you get
> > the full set of signatures)
> > 
> > If you want to upload a subset of attached artifacts to dist as part of
> > the
> > release, that seems much more tenable... just a derivative of the
> > scm-publish plugin from what I can see.
> > 
> > So I find myself in the space of trying to shoehorn our process into its
> > 
> >> the main maven-release-plugin, which I’ve found a tad difficult, versus
> >> writing our own release plugin, which feels like I would be duplicating
> >> tons of code (which I don’t want to do).
> > 
> > So the release plugin is really two parts:
> > 
> > 1. A toolkit for writing release plugins
> > 
> > 2. An example that does the job for the requirements of the Maven TLP and
> > has seemed “sufficient” for a lot of other people.
> > 
> > As such, if you have different needs, do not feel bad about having to
> > encode differently... hopefully the toolkit half of the codebase is
> > sufficient for you.
> > 
> >> I’m curious if you guys have any thoughts on the matter as I’ve been
> >> playing around in the space for a little while now.
> >> 
> >> Cheers and happy holidays from UTC-5,
> >> -Rob
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> <mailto:dev-unsubscr...@maven.apache.org> For additional commands,
> >> e-mail: dev-h...@maven.apache.org <mailto:dev-h...@maven.apache.org>
> >> 
> >> --
> > 
> > Sent from my phone



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Questions regarding improving the Apache Commons release process.

[Rob Tompkins]

Stephen,

I can’t thank you enough for your reply. I’ll take your suggestions and 
continue to sandbox around using the maven-release-plugin as a guideline.

All the best and happy holidays,
-Rob

> On Dec 26, 2017, at 5:27 AM, Stephen Connolly 
>  wrote:
> 
> On Tue 26 Dec 2017 at 03:10, Rob Tompkins  <mailto:chtom...@apache.org>> wrote:
> 
>> Hello all,
>> 
>> Pardon, maybe this should have gone to your @user list, but why not ping
>> the dev crew. I’ve been playing around the ideas surrounding our fairly
>> manual release process for the components in Commons, and I was hoping for
>> some insights.
>> 
>> Scripting the version changes isn’t really that big of a deal for us, and
>> that I can manage. But, when it comes to publishing our artifacts to the
>> apache nexus repository, and then separately publishing our -src and -bin
>> assemblies to the dev dist subversion repository (and consequently deleting
>> those artifacts from nexus as they’re “attached” for the purpose of gpg
>> signing), I feel it a tad cumbersome.
>> 
>> I’ve fiddled around a little with the idea of detaching the -src and -bin
>> assemblies after gpg signing with some success, but then I have to delve
>> into the mechanics of publishing those up to the subversion repository, and
>> clearly that problem has already been solved.
> 
> 
> Is your problem you don’t want those going to Nexus staging but only to
> dist? Or is it that you want them *also* going to dist.
> 
> Personally... I see no reason to remove them from going to Nexus staging
> (in fact I have a background plan to add secondary signing support to
> staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
> though. That would mean that the PMC would be able to *add* their GPG
> signature to the staged artifacts as part of the voting... in which case
> you’d want to hold off uploading to dist until *after* the vote so you get
> the full set of signatures)
> 
> If you want to upload a subset of attached artifacts to dist as part of the
> release, that seems much more tenable... just a derivative of the
> scm-publish plugin from what I can see.
> 
> So I find myself in the space of trying to shoehorn our process into its
>> the main maven-release-plugin, which I’ve found a tad difficult, versus
>> writing our own release plugin, which feels like I would be duplicating
>> tons of code (which I don’t want to do).
> 
> 
> So the release plugin is really two parts:
> 
> 1. A toolkit for writing release plugins
> 
> 2. An example that does the job for the requirements of the Maven TLP and
> has seemed “sufficient” for a lot of other people.
> 
> As such, if you have different needs, do not feel bad about having to
> encode differently... hopefully the toolkit half of the codebase is
> sufficient for you.
> 
>> 
>> 
>> I’m curious if you guys have any thoughts on the matter as I’ve been
>> playing around in the space for a little while now.
>> 
>> Cheers and happy holidays from UTC-5,
>> -Rob
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
>> <mailto:dev-unsubscr...@maven.apache.org>
>> For additional commands, e-mail: dev-h...@maven.apache.org 
>> <mailto:dev-h...@maven.apache.org>
>> 
>> --
> Sent from my phone

Re: Questions regarding improving the Apache Commons release process.

[sebb]

On 26 December 2017 at 18:48, Matt Sicker  wrote:
> On 26 December 2017 at 04:27, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Personally... I see no reason to remove them from going to Nexus staging
>> (in fact I have a background plan to add secondary signing support to
>> staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
>> though. That would mean that the PMC would be able to *add* their GPG
>> signature to the staged artifacts as part of the voting... in which case
>> you’d want to hold off uploading to dist until *after* the vote so you get
>> the full set of signatures)
>>

It would be better to upload the original files (including RM-only
sig) to dist/dev.
The updated sigs can always be replaced on dist/dev just before publication.

> Wow, this sounds really cool! So the PMC votes can add a vote by adding
> their GPG signature? That's a really nifty idea.
>
> --
> Matt Sicker 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Questions regarding improving the Apache Commons release process.

[Matt Sicker]

On 26 December 2017 at 04:27, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Personally... I see no reason to remove them from going to Nexus staging
> (in fact I have a background plan to add secondary signing support to
> staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
> though. That would mean that the PMC would be able to *add* their GPG
> signature to the staged artifacts as part of the voting... in which case
> you’d want to hold off uploading to dist until *after* the vote so you get
> the full set of signatures)
>

Wow, this sounds really cool! So the PMC votes can add a vote by adding
their GPG signature? That's a really nifty idea.

-- 
Matt Sicker 

Re: Questions regarding improving the Apache Commons release process.

[Stephen Connolly]

On Tue 26 Dec 2017 at 03:10, Rob Tompkins  wrote:

> Hello all,
>
> Pardon, maybe this should have gone to your @user list, but why not ping
> the dev crew. I’ve been playing around the ideas surrounding our fairly
> manual release process for the components in Commons, and I was hoping for
> some insights.
>
> Scripting the version changes isn’t really that big of a deal for us, and
> that I can manage. But, when it comes to publishing our artifacts to the
> apache nexus repository, and then separately publishing our -src and -bin
> assemblies to the dev dist subversion repository (and consequently deleting
> those artifacts from nexus as they’re “attached” for the purpose of gpg
> signing), I feel it a tad cumbersome.
>
> I’ve fiddled around a little with the idea of detaching the -src and -bin
> assemblies after gpg signing with some success, but then I have to delve
> into the mechanics of publishing those up to the subversion repository, and
> clearly that problem has already been solved.


Is your problem you don’t want those going to Nexus staging but only to
dist? Or is it that you want them *also* going to dist.

Personally... I see no reason to remove them from going to Nexus staging
(in fact I have a background plan to add secondary signing support to
staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
though. That would mean that the PMC would be able to *add* their GPG
signature to the staged artifacts as part of the voting... in which case
you’d want to hold off uploading to dist until *after* the vote so you get
the full set of signatures)

If you want to upload a subset of attached artifacts to dist as part of the
release, that seems much more tenable... just a derivative of the
scm-publish plugin from what I can see.

So I find myself in the space of trying to shoehorn our process into its
> the main maven-release-plugin, which I’ve found a tad difficult, versus
> writing our own release plugin, which feels like I would be duplicating
> tons of code (which I don’t want to do).


So the release plugin is really two parts:

1. A toolkit for writing release plugins

2. An example that does the job for the requirements of the Maven TLP and
has seemed “sufficient” for a lot of other people.

As such, if you have different needs, do not feel bad about having to
encode differently... hopefully the toolkit half of the codebase is
sufficient for you.

>
>
> I’m curious if you guys have any thoughts on the matter as I’ve been
> playing around in the space for a little while now.
>
> Cheers and happy holidays from UTC-5,
> -Rob
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Questions regarding improving the Apache Commons release process.

[Rob Tompkins]

Hello all,

Pardon, maybe this should have gone to your @user list, but why not ping the 
dev crew. I’ve been playing around the ideas surrounding our fairly manual 
release process for the components in Commons, and I was hoping for some 
insights. 

Scripting the version changes isn’t really that big of a deal for us, and that 
I can manage. But, when it comes to publishing our artifacts to the apache 
nexus repository, and then separately publishing our -src and -bin assemblies 
to the dev dist subversion repository (and consequently deleting those 
artifacts from nexus as they’re “attached” for the purpose of gpg signing), I 
feel it a tad cumbersome. 

I’ve fiddled around a little with the idea of detaching the -src and -bin 
assemblies after gpg signing with some success, but then I have to delve into 
the mechanics of publishing those up to the subversion repository, and clearly 
that problem has already been solved. So I find myself in the space of trying 
to shoehorn our process into its the main maven-release-plugin, which I’ve 
found a tad difficult, versus writing our own release plugin, which feels like 
I would be duplicating tons of code (which I don’t want to do).

I’m curious if you guys have any thoughts on the matter as I’ve been playing 
around in the space for a little while now.

Cheers and happy holidays from UTC-5,
-Rob
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [weaver] 1.3 release process

[Gary Gregory]

Go for it!

Gary

On Fri, Sep 30, 2016 at 9:55 AM, Matt Benson  wrote:

> Just a note to let the community I plan to start rolling release candidates
> in the near future.
>
> Matt
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[weaver] 1.3 release process

[Matt Benson]

Just a note to let the community I plan to start rolling release candidates
in the near future.

Matt

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

>From the time I spent recently perusing their API docs, I would guess from
the fact that they qualify the URL scheme with a "1" version, that they
will preserve compatibility indefinitely.  If they alter their API I
presume it will use a different version ID on the URL.

Matt


On Tue, Oct 15, 2013 at 2:08 PM, sebb  wrote:

> On 15 October 2013 19:33, Matt Benson  wrote:
> > Asked on #asfinfra and got the link from bdemers: [1].  He says it will
> > change to [2] whenever Nexus is upgraded.
>
> Thanks!
>
> Just to clarify: is it just the link that will change, or will the API
> change as well?
>
> > Matt
> > [1]
> >
> https://repository.apache.org/nexus-core-documentation-plugin/core/docs/index.html
> > [2]
> >
> https://repository.apache.org/nexus-restlet1x-plugin/default/docs/index.html
> >
> >
> >
> > On Tue, Oct 15, 2013 at 12:23 PM, sebb  wrote:
> >>
> >> On 15 October 2013 17:54, Matt Benson  wrote:
> >> > We should probably investigate whether Nexus's REST APIs would be of
> any
> >> > use here; seemingly they would make it much more difficult to
> >> > inadvertently
> >> > delete the wrong file(s).
> >>
> >> I did try to find out about them.
> >> Unfortunately they are not documented anywhere public that I could
> >> find (and it appears they may not be stable).
> >> I did make some progress by recording the GUI, but that is obviously not
> >> ideal.
> >>
> >> > Matt
> >> >
> >> >
> >> > On Tue, Oct 15, 2013 at 11:33 AM, sebb  wrote:
> >> >
> >> >> On 14 October 2013 02:21, Ralph Goers 
> >> >> wrote:
> >> >> >
> >> >> > On Oct 13, 2013, at 4:31 PM, sebb wrote:
> >> >> >
> >> >> >> Recently, I found that the Maven project RMs don't bother removing
> >> >> these.
> >> >> >> So the files are released to Maven Central with the rest.
> >> >> >> I assume that the Maven Central administrators don't care about
> the
> >> >> >> extra space needed.
> >> >> >>
> >> >> >> Now ASF source releases must be provided via the ASF mirror
> system.
> >> >> >> There does not seem to be any ruling on whether having additional
> >> >> >> copies of the source release elsehere is allowed or not.
> >> >> >>
> >> >> >> I tried asking on Infra whether source releases should only be
> >> >> >> published to the ASF mirror system, but got no answer.
> >> >> >> Perhaps someone else would like to try?
> >> >> >>
> >> >> >> It would obviously be a lot easier if the Nexus directory did not
> >> >> >> have
> >> >> >> to be purged of these files, as this has to be carefully
> >> >> >> co-ordinated
> >> >> >> with copying the files for the ASF mirror SVN repo.
> >> >> >
> >> >> > Whether they have to be removed or not as a user I find them being
> >> >> published to Maven central to be annoying since they are pretty much
> >> >> useless as Maven artifacts.
> >> >>
> >> >> Indeed.
> >> >>
> >> >> The issue here is that deleting files from a closed staging area is
> >> >> prone to errors as the Nexus GUI is quite fiddly (and the
> confirmation
> >> >> pop-up does not show the name of the file being deleted).
> >> >>
> >> >> >
> >> >> >>
> >> >> >>> I gave up trying to remove the absurd .asc.sha1 and
> >> >> >>> .asc.md5 files for JCI, there was too many of them (12 files per
> >> >> >>> artifact, 6 artifacts).
> >> >> >>
> >> >> >> That could be automated (I started working on a tool to do this,
> but
> >> >> >> other things intervened).
> >> >> >> It's a long-standing Maven bug. The files can be left, but it
> makes
> >> >> >> checking the directory tedious.
> >> >> >
> >> >> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c.
>  I'm
> >> >> not sure why rm *.asc.md5 is a problem.  Even if they are in separate
> >> >> directories the find command works pretty well.
> >> >>
> >> >> Find and rm do not work on Nexus, which is one place where the
> >> >> spurious files are annoying.
> >> >> Also it's easy to delete the wrong file in Nexus (so this should be
> >> >> done before closing the staging area - if it is done at all)
> >> >>
> >> >> > Ralph
> >> >> >
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >> >>
> >> >>
> >
> >
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[sebb]

On 15 October 2013 19:33, Matt Benson  wrote:
> Asked on #asfinfra and got the link from bdemers: [1].  He says it will
> change to [2] whenever Nexus is upgraded.

Thanks!

Just to clarify: is it just the link that will change, or will the API
change as well?

> Matt
> [1]
> https://repository.apache.org/nexus-core-documentation-plugin/core/docs/index.html
> [2]
> https://repository.apache.org/nexus-restlet1x-plugin/default/docs/index.html
>
>
>
> On Tue, Oct 15, 2013 at 12:23 PM, sebb  wrote:
>>
>> On 15 October 2013 17:54, Matt Benson  wrote:
>> > We should probably investigate whether Nexus's REST APIs would be of any
>> > use here; seemingly they would make it much more difficult to
>> > inadvertently
>> > delete the wrong file(s).
>>
>> I did try to find out about them.
>> Unfortunately they are not documented anywhere public that I could
>> find (and it appears they may not be stable).
>> I did make some progress by recording the GUI, but that is obviously not
>> ideal.
>>
>> > Matt
>> >
>> >
>> > On Tue, Oct 15, 2013 at 11:33 AM, sebb  wrote:
>> >
>> >> On 14 October 2013 02:21, Ralph Goers 
>> >> wrote:
>> >> >
>> >> > On Oct 13, 2013, at 4:31 PM, sebb wrote:
>> >> >
>> >> >> Recently, I found that the Maven project RMs don't bother removing
>> >> these.
>> >> >> So the files are released to Maven Central with the rest.
>> >> >> I assume that the Maven Central administrators don't care about the
>> >> >> extra space needed.
>> >> >>
>> >> >> Now ASF source releases must be provided via the ASF mirror system.
>> >> >> There does not seem to be any ruling on whether having additional
>> >> >> copies of the source release elsehere is allowed or not.
>> >> >>
>> >> >> I tried asking on Infra whether source releases should only be
>> >> >> published to the ASF mirror system, but got no answer.
>> >> >> Perhaps someone else would like to try?
>> >> >>
>> >> >> It would obviously be a lot easier if the Nexus directory did not
>> >> >> have
>> >> >> to be purged of these files, as this has to be carefully
>> >> >> co-ordinated
>> >> >> with copying the files for the ASF mirror SVN repo.
>> >> >
>> >> > Whether they have to be removed or not as a user I find them being
>> >> published to Maven central to be annoying since they are pretty much
>> >> useless as Maven artifacts.
>> >>
>> >> Indeed.
>> >>
>> >> The issue here is that deleting files from a closed staging area is
>> >> prone to errors as the Nexus GUI is quite fiddly (and the confirmation
>> >> pop-up does not show the name of the file being deleted).
>> >>
>> >> >
>> >> >>
>> >> >>> I gave up trying to remove the absurd .asc.sha1 and
>> >> >>> .asc.md5 files for JCI, there was too many of them (12 files per
>> >> >>> artifact, 6 artifacts).
>> >> >>
>> >> >> That could be automated (I started working on a tool to do this, but
>> >> >> other things intervened).
>> >> >> It's a long-standing Maven bug. The files can be left, but it makes
>> >> >> checking the directory tedious.
>> >> >
>> >> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c.  I'm
>> >> not sure why rm *.asc.md5 is a problem.  Even if they are in separate
>> >> directories the find command works pretty well.
>> >>
>> >> Find and rm do not work on Nexus, which is one place where the
>> >> spurious files are annoying.
>> >> Also it's easy to delete the wrong file in Nexus (so this should be
>> >> done before closing the staging area - if it is done at all)
>> >>
>> >> > Ralph
>> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> >> For additional commands, e-mail: dev-h...@commons.apache.org
>> >>
>> >>
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

Asked on #asfinfra and got the link from bdemers: [1].  He says it will
change to [2] whenever Nexus is upgraded.

Matt
[1]
https://repository.apache.org/nexus-core-documentation-plugin/core/docs/index.html
[2]
https://repository.apache.org/nexus-restlet1x-plugin/default/docs/index.html



On Tue, Oct 15, 2013 at 12:23 PM, sebb  wrote:

> On 15 October 2013 17:54, Matt Benson  wrote:
> > We should probably investigate whether Nexus's REST APIs would be of any
> > use here; seemingly they would make it much more difficult to
> inadvertently
> > delete the wrong file(s).
>
> I did try to find out about them.
> Unfortunately they are not documented anywhere public that I could
> find (and it appears they may not be stable).
> I did make some progress by recording the GUI, but that is obviously not
> ideal.
>
> > Matt
> >
> >
> > On Tue, Oct 15, 2013 at 11:33 AM, sebb  wrote:
> >
> >> On 14 October 2013 02:21, Ralph Goers 
> wrote:
> >> >
> >> > On Oct 13, 2013, at 4:31 PM, sebb wrote:
> >> >
> >> >> Recently, I found that the Maven project RMs don't bother removing
> >> these.
> >> >> So the files are released to Maven Central with the rest.
> >> >> I assume that the Maven Central administrators don't care about the
> >> >> extra space needed.
> >> >>
> >> >> Now ASF source releases must be provided via the ASF mirror system.
> >> >> There does not seem to be any ruling on whether having additional
> >> >> copies of the source release elsehere is allowed or not.
> >> >>
> >> >> I tried asking on Infra whether source releases should only be
> >> >> published to the ASF mirror system, but got no answer.
> >> >> Perhaps someone else would like to try?
> >> >>
> >> >> It would obviously be a lot easier if the Nexus directory did not
> have
> >> >> to be purged of these files, as this has to be carefully co-ordinated
> >> >> with copying the files for the ASF mirror SVN repo.
> >> >
> >> > Whether they have to be removed or not as a user I find them being
> >> published to Maven central to be annoying since they are pretty much
> >> useless as Maven artifacts.
> >>
> >> Indeed.
> >>
> >> The issue here is that deleting files from a closed staging area is
> >> prone to errors as the Nexus GUI is quite fiddly (and the confirmation
> >> pop-up does not show the name of the file being deleted).
> >>
> >> >
> >> >>
> >> >>> I gave up trying to remove the absurd .asc.sha1 and
> >> >>> .asc.md5 files for JCI, there was too many of them (12 files per
> >> >>> artifact, 6 artifacts).
> >> >>
> >> >> That could be automated (I started working on a tool to do this, but
> >> >> other things intervened).
> >> >> It's a long-standing Maven bug. The files can be left, but it makes
> >> >> checking the directory tedious.
> >> >
> >> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c.  I'm
> >> not sure why rm *.asc.md5 is a problem.  Even if they are in separate
> >> directories the find command works pretty well.
> >>
> >> Find and rm do not work on Nexus, which is one place where the
> >> spurious files are annoying.
> >> Also it's easy to delete the wrong file in Nexus (so this should be
> >> done before closing the staging area - if it is done at all)
> >>
> >> > Ralph
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[sebb]

On 15 October 2013 17:54, Matt Benson  wrote:
> We should probably investigate whether Nexus's REST APIs would be of any
> use here; seemingly they would make it much more difficult to inadvertently
> delete the wrong file(s).

I did try to find out about them.
Unfortunately they are not documented anywhere public that I could
find (and it appears they may not be stable).
I did make some progress by recording the GUI, but that is obviously not ideal.

> Matt
>
>
> On Tue, Oct 15, 2013 at 11:33 AM, sebb  wrote:
>
>> On 14 October 2013 02:21, Ralph Goers  wrote:
>> >
>> > On Oct 13, 2013, at 4:31 PM, sebb wrote:
>> >
>> >> Recently, I found that the Maven project RMs don't bother removing
>> these.
>> >> So the files are released to Maven Central with the rest.
>> >> I assume that the Maven Central administrators don't care about the
>> >> extra space needed.
>> >>
>> >> Now ASF source releases must be provided via the ASF mirror system.
>> >> There does not seem to be any ruling on whether having additional
>> >> copies of the source release elsehere is allowed or not.
>> >>
>> >> I tried asking on Infra whether source releases should only be
>> >> published to the ASF mirror system, but got no answer.
>> >> Perhaps someone else would like to try?
>> >>
>> >> It would obviously be a lot easier if the Nexus directory did not have
>> >> to be purged of these files, as this has to be carefully co-ordinated
>> >> with copying the files for the ASF mirror SVN repo.
>> >
>> > Whether they have to be removed or not as a user I find them being
>> published to Maven central to be annoying since they are pretty much
>> useless as Maven artifacts.
>>
>> Indeed.
>>
>> The issue here is that deleting files from a closed staging area is
>> prone to errors as the Nexus GUI is quite fiddly (and the confirmation
>> pop-up does not show the name of the file being deleted).
>>
>> >
>> >>
>> >>> I gave up trying to remove the absurd .asc.sha1 and
>> >>> .asc.md5 files for JCI, there was too many of them (12 files per
>> >>> artifact, 6 artifacts).
>> >>
>> >> That could be automated (I started working on a tool to do this, but
>> >> other things intervened).
>> >> It's a long-standing Maven bug. The files can be left, but it makes
>> >> checking the directory tedious.
>> >
>> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c.  I'm
>> not sure why rm *.asc.md5 is a problem.  Even if they are in separate
>> directories the find command works pretty well.
>>
>> Find and rm do not work on Nexus, which is one place where the
>> spurious files are annoying.
>> Also it's easy to delete the wrong file in Nexus (so this should be
>> done before closing the staging area - if it is done at all)
>>
>> > Ralph
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

We should probably investigate whether Nexus's REST APIs would be of any
use here; seemingly they would make it much more difficult to inadvertently
delete the wrong file(s).

Matt


On Tue, Oct 15, 2013 at 11:33 AM, sebb  wrote:

> On 14 October 2013 02:21, Ralph Goers  wrote:
> >
> > On Oct 13, 2013, at 4:31 PM, sebb wrote:
> >
> >> Recently, I found that the Maven project RMs don't bother removing
> these.
> >> So the files are released to Maven Central with the rest.
> >> I assume that the Maven Central administrators don't care about the
> >> extra space needed.
> >>
> >> Now ASF source releases must be provided via the ASF mirror system.
> >> There does not seem to be any ruling on whether having additional
> >> copies of the source release elsehere is allowed or not.
> >>
> >> I tried asking on Infra whether source releases should only be
> >> published to the ASF mirror system, but got no answer.
> >> Perhaps someone else would like to try?
> >>
> >> It would obviously be a lot easier if the Nexus directory did not have
> >> to be purged of these files, as this has to be carefully co-ordinated
> >> with copying the files for the ASF mirror SVN repo.
> >
> > Whether they have to be removed or not as a user I find them being
> published to Maven central to be annoying since they are pretty much
> useless as Maven artifacts.
>
> Indeed.
>
> The issue here is that deleting files from a closed staging area is
> prone to errors as the Nexus GUI is quite fiddly (and the confirmation
> pop-up does not show the name of the file being deleted).
>
> >
> >>
> >>> I gave up trying to remove the absurd .asc.sha1 and
> >>> .asc.md5 files for JCI, there was too many of them (12 files per
> >>> artifact, 6 artifacts).
> >>
> >> That could be automated (I started working on a tool to do this, but
> >> other things intervened).
> >> It's a long-standing Maven bug. The files can be left, but it makes
> >> checking the directory tedious.
> >
> > See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c.  I'm
> not sure why rm *.asc.md5 is a problem.  Even if they are in separate
> directories the find command works pretty well.
>
> Find and rm do not work on Nexus, which is one place where the
> spurious files are annoying.
> Also it's easy to delete the wrong file in Nexus (so this should be
> done before closing the staging area - if it is done at all)
>
> > Ralph
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[sebb]

On 14 October 2013 02:21, Ralph Goers  wrote:
>
> On Oct 13, 2013, at 4:31 PM, sebb wrote:
>
>> Recently, I found that the Maven project RMs don't bother removing these.
>> So the files are released to Maven Central with the rest.
>> I assume that the Maven Central administrators don't care about the
>> extra space needed.
>>
>> Now ASF source releases must be provided via the ASF mirror system.
>> There does not seem to be any ruling on whether having additional
>> copies of the source release elsehere is allowed or not.
>>
>> I tried asking on Infra whether source releases should only be
>> published to the ASF mirror system, but got no answer.
>> Perhaps someone else would like to try?
>>
>> It would obviously be a lot easier if the Nexus directory did not have
>> to be purged of these files, as this has to be carefully co-ordinated
>> with copying the files for the ASF mirror SVN repo.
>
> Whether they have to be removed or not as a user I find them being published 
> to Maven central to be annoying since they are pretty much useless as Maven 
> artifacts.

Indeed.

The issue here is that deleting files from a closed staging area is
prone to errors as the Nexus GUI is quite fiddly (and the confirmation
pop-up does not show the name of the file being deleted).

>
>>
>>> I gave up trying to remove the absurd .asc.sha1 and
>>> .asc.md5 files for JCI, there was too many of them (12 files per
>>> artifact, 6 artifacts).
>>
>> That could be automated (I started working on a tool to do this, but
>> other things intervened).
>> It's a long-standing Maven bug. The files can be left, but it makes
>> checking the directory tedious.
>
> See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c.  I'm not sure 
> why rm *.asc.md5 is a problem.  Even if they are in separate directories the 
> find command works pretty well.

Find and rm do not work on Nexus, which is one place where the
spurious files are annoying.
Also it's easy to delete the wrong file in Nexus (so this should be
done before closing the staging area - if it is done at all)

> Ralph
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Ralph Goers]

On Oct 13, 2013, at 4:31 PM, sebb wrote:

> Recently, I found that the Maven project RMs don't bother removing these.
> So the files are released to Maven Central with the rest.
> I assume that the Maven Central administrators don't care about the
> extra space needed.
> 
> Now ASF source releases must be provided via the ASF mirror system.
> There does not seem to be any ruling on whether having additional
> copies of the source release elsehere is allowed or not.
> 
> I tried asking on Infra whether source releases should only be
> published to the ASF mirror system, but got no answer.
> Perhaps someone else would like to try?
> 
> It would obviously be a lot easier if the Nexus directory did not have
> to be purged of these files, as this has to be carefully co-ordinated
> with copying the files for the ASF mirror SVN repo.

Whether they have to be removed or not as a user I find them being published to 
Maven central to be annoying since they are pretty much useless as Maven 
artifacts.


> 
>> I gave up trying to remove the absurd .asc.sha1 and
>> .asc.md5 files for JCI, there was too many of them (12 files per
>> artifact, 6 artifacts).
> 
> That could be automated (I started working on a tool to do this, but
> other things intervened).
> It's a long-standing Maven bug. The files can be left, but it makes
> checking the directory tedious.

See http://wiki.apache.org/logging/Log4j2ReleaseGuide step 11c.  I'm not sure 
why rm *.asc.md5 is a problem.  Even if they are in separate directories the 
find command works pretty well.

Ralph

Re: [DISCUSS] Creating Project for Release Process Testing...

[sebb]

On 11 October 2013 10:23, Emmanuel Bourg  wrote:
> Le 11/10/2013 01:35, Matt Benson a écrit :
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons.  I think it would be immensely
>> helpful for those of us who have been at least part way through the process
>> fairly recently (Emmanuel, Gary, others?) to present your recollections of
>> what was difficult, so that we can have a real list of things to try and
>> address.
>
> Here is my quick feed back on the release process. For the record I
> prepared the release on Windows by following the 'Using Nexus for
> Commons Maven releases' guide [1]. I also took some bits from the
> 'Releasing Components' guide [2] (unifying these documents would be a
> good start).
>
> 1. The initial setup is a bit tedious. Generating the GPG key, uploading
> it, configuring the agent, adding the Maven settings. This is not fun
> and sometimes frustrating (I didn't set my ASF password properly in the
> Maven settings and I had to reset it twice. Nexus rejected my uploads
> with a 401 error but I didn't figure my account was locked until I found
> myself unable to commit a change in SVN). Hopefully all of this is
> performed only once.
>
> 2. The Nexus UI is a bit confusing when you are not used to it. Between
> User Managed Repositories, Nexus Managed Repositories and Staging
> Repositories it wasn't obvious at the first glance to see where the
> action was supposed to take place. A mini howto with annotated
> screenshots would help.
>
> 3. Having to drop manually the -src and -bin artifacts uploaded to Nexus
> is annoying.

Recently, I found that the Maven project RMs don't bother removing these.
So the files are released to Maven Central with the rest.
I assume that the Maven Central administrators don't care about the
extra space needed.

Now ASF source releases must be provided via the ASF mirror system.
There does not seem to be any ruling on whether having additional
copies of the source release elsehere is allowed or not.

I tried asking on Infra whether source releases should only be
published to the ASF mirror system, but got no answer.
Perhaps someone else would like to try?

It would obviously be a lot easier if the Nexus directory did not have
to be purged of these files, as this has to be carefully co-ordinated
with copying the files for the ASF mirror SVN repo.

> I gave up trying to remove the absurd .asc.sha1 and
> .asc.md5 files for JCI, there was too many of them (12 files per
> artifact, 6 artifacts).

That could be automated (I started working on a tool to do this, but
other things intervened).
It's a long-standing Maven bug. The files can be left, but it makes
checking the directory tedious.

> 4. Preparing the release notes is time consuming. I know it can be
> generated from JIRA but I don't find that descriptive enough. Using the
> Maven changes.xml is the best solution, but it has to be maintained
> properly during the development (it wasn't for JCI).

With NET I went through JIRA looking at the "Fix" version to check
that all the issues were in changes.xml.

> 5. I created the tag manually, that was simple enough. I don't trust the
> release plugin. I guess I need some training on a dummy project. Due to
> minor errors spotted afterward I had to recreate the tag twice. So I
> suggest creating the tag only when you have reviewed everything and
> about to send the vote mail.

The release plugin works best if the release vote succeeds; it's messy
if a respin is needed.
There will be SNAPSHOT releases (generated by CI) with the next version in them.
If the release vote fails, these can hang around for a while, causing
possible confusion once trunk moves on as they will become stale.

> 6. 'mvn site:stage-deploy' doesn't work. I got the message
> "maven.site.deploy.skip = true: Skipping site deployment". This property
> is set in the parent pom! I had to tar the site, upload and install it
> manually on people.apache.org.
>
> 7. I would like a [VOTE] mail generator :)
>
> 8. Uploading the source and the binary archives on people.apache.org
> implies too many manual steps. This has to be automated (with a Maven
> plugin attached to the deploy phase?).

Automating that was one of the plugins I started working on.
However, it must be done after the vote has succeeded, unless the
files are copied to the dev (staging) repo.
In which case there are then two staging areas to consider for the vote.
It's easier to use Nexus for both.

None of these problems are due to using SVN; most (all?) of these
problems are due to using Maven.

>
> Emmanu

Re: [DISCUSS] Creating Project for Release Process Testing...

[sebb]

On 11 October 2013 05:16, Stefan Bodewig  wrote:
> On 2013-10-11, Matt Benson wrote:
>
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons.  I think it would be immensely
>> helpful for those of us who have been at least part way through the process
>> fairly recently (Emmanuel, Gary, others?) to present your recollections of
>> what was difficult, so that we can have a real list of things to try and
>> address.
>
> Not sure whether May is recent enough :-)
>
> AFAIR there isn't anything difficult.  The major pain point for me is
> the sheer number of manual steps - with it comes a big number of
> opportunities to make mistakes - and the time it takes.
>
> One detail I just figured out after my third release was that I can
> start the gpg-agent before running "mvn deploy" - and I think I've
> documented that.  Without that I had to type in my passphrase for every
> single artifact.

With my setup, the gpg-agent is started automatically.
I use Window; maybe gpg works differently on Unix.

> I prefer the "create the tag manually and avoid the release plugin"

Ditto.

> approach but don't think there is a big difference here.

> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Emmanuel Bourg]

Le 12/10/2013 10:07, Olivier Lamy a écrit :

> Why removing those files? It's is strictly forbidden by any Apache
> rules to have those?

No, but it just clutters Maven Central. The .asc file contains a signed
hash of the file, there is no need to have two additional hashes of a hash.


> why creating tag manually? I believe release plugin does it.

I'm just not used to it, so I picked the safest solution for me. This is
where the test component will be useful, it will allow new release
managers to experiment with the tools involved.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

Phil, I'm for whatever makes it easier.  In the new release test project,
let's start "green field" and see what we come up with.  If we see enough
boilerplate to merit a parent, then we will extract those bits and make
one.  If not, then it's every component for themselves.

On Sunday, October 13, 2013, Phil Steitz wrote:

> On 10/11/13 3:53 AM, Gilles wrote:
> > On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
> >> We're all still talking about the release process, but in all
> >> honesty I've
> >> not done it for several years at Commons.  I think it would be
> >> immensely
> >> helpful for those of us who have been at least part way through
> >> the process
> >> fairly recently (Emmanuel, Gary, others?) to present your
> >> recollections of
> >> what was difficult, so that we can have a real list of things to
> >> try and
> >> address.
> >>
> >
> > There is a mini-howto for Commons Math here:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt
> >
> > The aim was to provide a fool-proof, step-by-step recipe, which
> > the "official"
> > Wiki documents were _not_: The missing bits were filled as a
> > summary of my
> > interaction with the ML (cf. archive).
> > [Luc upgraded the document after the CMS change.]
> >
> > Nothing is "complicated"; following the recipe should allow anyone
> > to make a
> > release.
> > As was noted in another post:
> >  * several steps could be made faster with scripting
>
> +1 and once again THANKs for documenting this stuff for [math],
> Gilles.  I have not cut a release since the forced Nexus days, but
> before then, I always used shell scripts that I eventually committed
> to svn to make it "just push the button" the next time I did it.  An
> example is [1], which no longer works due to changes in commons
> parent, maven plugins and the Nexus requirement; but if and when I
> cut another release there or on anything else, I will likely just
> update it so .(n+k) are easy.  After doing the work to create [1]
> for [pool] 1.5, 1.5.1-1.5.7 were trivial for me. The problem with
> this approach is that it requires a unix shell and it also punts the
> "let maven automagially do everything" desire.  Personally, I much
> prefer the srcipt approach as I know exactly what is happening.
>
> This brings up another point that has been sort of in the background
> here.  I don't think it is a defeat to have individual components
> have their own RM READMEs.  Trying to solve the problem generically
> for all components increases the degree of difficulty and the
> probability that people will run into little problems.  I have felt
> this way for a long time regarding the commons parent pom as well.
> It might be better to destandardize a little, slim down the parent
> (or dump it altogether) and allow component RMs to develop things
> like [1] and Gilles' instructions above, without aiming to solve the
> problem generically for all components.  When you think about it,
> what we have have been struggling with here is generic release
> tooling for java components @apache, which is in theory possible,
> but with sometimes flaky and changing underlying tools (maven
> plugins, nexus) and little edge cases to consider at the component
> level, we end up burning ridiculously more energy and having to
> fiddle more often than if we just maintained little scripts/READMEs
> at the component level.  We could maintain general instructions
> explaining what is *required* and just use the time honored Commons
> tradition of imitating other components to get and keep the
> individual RC scripts working.  As a concrete example, I would like
> to see us experiment with the tomcat approach to deployment [2] for
> pool2 and dbcp2, but I don't want to force everyone down this path
> or get everyone to agree to it.
>
> Phil
>
> [1]
> https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh
> [2] http://markmail.org/message/kkualb7xse2mcwkd
>
> >  * removing spurious files from Nexus is a pain after a few RCs
> >
> >
> > Regards,
> > Gilles
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

I understand your frustration, Phil, particularly if you're the type who
has never liked the flavor of the Maven kool-aid... I know I struggled
fruitlessly for years against Maven! However, the biggest benefit I see to
the parent pom is the site management.  I can't justify us propping up some
custom site management solution, personally. I suppose that if we can get
the Maven fluido skin working and agree on a bootstrap style, it could
become an option for a given component to use the straight CMS with that
style and bypass the Maven site. But I do think some measure of cosmetic
unity among the component sites should be maintained.

Matt
On Oct 13, 2013 12:20 PM, "Phil Steitz"  wrote:

> On 10/11/13 3:53 AM, Gilles wrote:
> > On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
> >> We're all still talking about the release process, but in all
> >> honesty I've
> >> not done it for several years at Commons.  I think it would be
> >> immensely
> >> helpful for those of us who have been at least part way through
> >> the process
> >> fairly recently (Emmanuel, Gary, others?) to present your
> >> recollections of
> >> what was difficult, so that we can have a real list of things to
> >> try and
> >> address.
> >>
> >
> > There is a mini-howto for Commons Math here:
> >
> >
> https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt
> >
> > The aim was to provide a fool-proof, step-by-step recipe, which
> > the "official"
> > Wiki documents were _not_: The missing bits were filled as a
> > summary of my
> > interaction with the ML (cf. archive).
> > [Luc upgraded the document after the CMS change.]
> >
> > Nothing is "complicated"; following the recipe should allow anyone
> > to make a
> > release.
> > As was noted in another post:
> >  * several steps could be made faster with scripting
>
> +1 and once again THANKs for documenting this stuff for [math],
> Gilles.  I have not cut a release since the forced Nexus days, but
> before then, I always used shell scripts that I eventually committed
> to svn to make it "just push the button" the next time I did it.  An
> example is [1], which no longer works due to changes in commons
> parent, maven plugins and the Nexus requirement; but if and when I
> cut another release there or on anything else, I will likely just
> update it so .(n+k) are easy.  After doing the work to create [1]
> for [pool] 1.5, 1.5.1-1.5.7 were trivial for me. The problem with
> this approach is that it requires a unix shell and it also punts the
> "let maven automagially do everything" desire.  Personally, I much
> prefer the srcipt approach as I know exactly what is happening.
>
> This brings up another point that has been sort of in the background
> here.  I don't think it is a defeat to have individual components
> have their own RM READMEs.  Trying to solve the problem generically
> for all components increases the degree of difficulty and the
> probability that people will run into little problems.  I have felt
> this way for a long time regarding the commons parent pom as well.
> It might be better to destandardize a little, slim down the parent
> (or dump it altogether) and allow component RMs to develop things
> like [1] and Gilles' instructions above, without aiming to solve the
> problem generically for all components.  When you think about it,
> what we have have been struggling with here is generic release
> tooling for java components @apache, which is in theory possible,
> but with sometimes flaky and changing underlying tools (maven
> plugins, nexus) and little edge cases to consider at the component
> level, we end up burning ridiculously more energy and having to
> fiddle more often than if we just maintained little scripts/READMEs
> at the component level.  We could maintain general instructions
> explaining what is *required* and just use the time honored Commons
> tradition of imitating other components to get and keep the
> individual RC scripts working.  As a concrete example, I would like
> to see us experiment with the tomcat approach to deployment [2] for
> pool2 and dbcp2, but I don't want to force everyone down this path
> or get everyone to agree to it.
>
> Phil
>
> [1]
> https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh
> [2] http://markmail.org/message/kkualb7xse2mcwkd
>
> >  * removing spurious files from Nexus is a pain after a few RCs
> >
> >
> > Regards,
> > Gilles
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[Phil Steitz]

On 10/11/13 3:53 AM, Gilles wrote:
> On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
>> We're all still talking about the release process, but in all
>> honesty I've
>> not done it for several years at Commons.  I think it would be
>> immensely
>> helpful for those of us who have been at least part way through
>> the process
>> fairly recently (Emmanuel, Gary, others?) to present your
>> recollections of
>> what was difficult, so that we can have a real list of things to
>> try and
>> address.
>>
>
> There is a mini-howto for Commons Math here:
>  
> https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt
>
> The aim was to provide a fool-proof, step-by-step recipe, which
> the "official"
> Wiki documents were _not_: The missing bits were filled as a
> summary of my
> interaction with the ML (cf. archive).
> [Luc upgraded the document after the CMS change.]
>
> Nothing is "complicated"; following the recipe should allow anyone
> to make a
> release.
> As was noted in another post:
>  * several steps could be made faster with scripting

+1 and once again THANKs for documenting this stuff for [math],
Gilles.  I have not cut a release since the forced Nexus days, but
before then, I always used shell scripts that I eventually committed
to svn to make it "just push the button" the next time I did it.  An
example is [1], which no longer works due to changes in commons
parent, maven plugins and the Nexus requirement; but if and when I
cut another release there or on anything else, I will likely just
update it so .(n+k) are easy.  After doing the work to create [1]
for [pool] 1.5, 1.5.1-1.5.7 were trivial for me. The problem with
this approach is that it requires a unix shell and it also punts the
"let maven automagially do everything" desire.  Personally, I much
prefer the srcipt approach as I know exactly what is happening.

This brings up another point that has been sort of in the background
here.  I don't think it is a defeat to have individual components
have their own RM READMEs.  Trying to solve the problem generically
for all components increases the degree of difficulty and the
probability that people will run into little problems.  I have felt
this way for a long time regarding the commons parent pom as well. 
It might be better to destandardize a little, slim down the parent
(or dump it altogether) and allow component RMs to develop things
like [1] and Gilles' instructions above, without aiming to solve the
problem generically for all components.  When you think about it,
what we have have been struggling with here is generic release
tooling for java components @apache, which is in theory possible,
but with sometimes flaky and changing underlying tools (maven
plugins, nexus) and little edge cases to consider at the component
level, we end up burning ridiculously more energy and having to
fiddle more often than if we just maintained little scripts/READMEs
at the component level.  We could maintain general instructions
explaining what is *required* and just use the time honored Commons
tradition of imitating other components to get and keep the
individual RC scripts working.  As a concrete example, I would like
to see us experiment with the tomcat approach to deployment [2] for
pool2 and dbcp2, but I don't want to force everyone down this path
or get everyone to agree to it.

Phil

[1]
https://svn.apache.org/repos/asf/commons/proper/pool/trunk/pool-RC.sh
[2] http://markmail.org/message/kkualb7xse2mcwkd

>  * removing spurious files from Nexus is a pain after a few RCs
>
>
> Regards,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

JIRA created:

https://issues.apache.org/jira/browse/INFRA-6859


On Sun, Oct 13, 2013 at 4:17 AM, Siegfried Goeschl
 wrote:
> +1 on that
>
> I did a few releases over the year and had ALWAYS issues - for me the
> biggest obstacles are
>
> * getting a positive vote on a RC (that's a different story)
> * getting the release out of the door - a test project would help immensely
> since I can blow it up without any consequences
>
> Cheers,
>
> Siegfried Goeschl
>
>
> On 10.10.13 17:29, Gary Gregory wrote:
>>
>> Nice idea, but push it to central to test the whole chain.
>>
>> G
>>
>> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
>>  wrote:
>>>
>>> Why don't we create a real project that we can cut real releases on to
>>> test our release procedures?  Perhaps we can set it up so that it
>>> doesn't sync with central and just gets staged locally.  This way, we
>>> can test out changes to the release process and see how they work.
>>> Also, a new release manager can play around with that project and get
>>> it right before diving into the real work.
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Siegfried Goeschl]

+1 on that

I did a few releases over the year and had ALWAYS issues - for me the 
biggest obstacles are


* getting a positive vote on a RC (that's a different story)
* getting the release out of the door - a test project would help 
immensely since I can blow it up without any consequences


Cheers,

Siegfried Goeschl

On 10.10.13 17:29, Gary Gregory wrote:

Nice idea, but push it to central to test the whole chain.

G

On Thu, Oct 10, 2013 at 11:24 AM, James Carman
 wrote:

Why don't we create a real project that we can cut real releases on to
test our release procedures?  Perhaps we can set it up so that it
doesn't sync with central and just gets staged locally.  This way, we
can test out changes to the release process and see how they work.
Also, a new release manager can play around with that project and get
it right before diving into the real work.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Olivier Lamy]

On 11 October 2013 20:23, Emmanuel Bourg  wrote:
> Le 11/10/2013 01:35, Matt Benson a écrit :
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons.  I think it would be immensely
>> helpful for those of us who have been at least part way through the process
>> fairly recently (Emmanuel, Gary, others?) to present your recollections of
>> what was difficult, so that we can have a real list of things to try and
>> address.
>
> Here is my quick feed back on the release process. For the record I
> prepared the release on Windows by following the 'Using Nexus for
> Commons Maven releases' guide [1]. I also took some bits from the
> 'Releasing Components' guide [2] (unifying these documents would be a
> good start).
>
> 1. The initial setup is a bit tedious. Generating the GPG key, uploading
> it, configuring the agent, adding the Maven settings. This is not fun
> and sometimes frustrating (I didn't set my ASF password properly in the
> Maven settings and I had to reset it twice. Nexus rejected my uploads
> with a 401 error but I didn't figure my account was locked until I found
> myself unable to commit a change in SVN). Hopefully all of this is
> performed only once.
>
> 2. The Nexus UI is a bit confusing when you are not used to it. Between
> User Managed Repositories, Nexus Managed Repositories and Staging
> Repositories it wasn't obvious at the first glance to see where the
> action was supposed to take place. A mini howto with annotated
> screenshots would help.
>
> 3. Having to drop manually the -src and -bin artifacts uploaded to Nexus
> is annoying. I gave up trying to remove the absurd .asc.sha1 and
> .asc.md5 files for JCI, there was too many of them (12 files per
> artifact, 6 artifacts).

Why removing those files? It's is strictly forbidden by any Apache
rules to have those?

>
> 4. Preparing the release notes is time consuming. I know it can be
> generated from JIRA but I don't find that descriptive enough. Using the
> Maven changes.xml is the best solution, but it has to be maintained
> properly during the development (it wasn't for JCI).
>
> 5. I created the tag manually, that was simple enough. I don't trust the
> release plugin. I guess I need some training on a dummy project. Due to
> minor errors spotted afterward I had to recreate the tag twice. So I
> suggest creating the tag only when you have reviewed everything and
> about to send the vote mail.

why creating tag manually? I believe release plugin does it.

>
> 6. 'mvn site:stage-deploy' doesn't work. I got the message
> "maven.site.deploy.skip = true: Skipping site deployment". This property
> is set in the parent pom! I had to tar the site, upload and install it
> manually on people.apache.org.

probably something not complicated to fix.

>
> 7. I would like a [VOTE] mail generator :)

Agree too.

>
> 8. Uploading the source and the binary archives on people.apache.org
> implies too many manual steps. This has to be automated (with a Maven
> plugin attached to the deploy phase?).
>

Agree too (something I wanted to do but not having time to work on it).

I don't understand why you guys are adding manual steps (whereas tools exists).

>
> Emmanuel Bourg
>
> [1] http://wiki.apache.org/commons/UsingNexus
> [2] http://commons.apache.org/releases/
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Gilles]

On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
We're all still talking about the release process, but in all honesty 
I've
not done it for several years at Commons.  I think it would be 
immensely
helpful for those of us who have been at least part way through the 
process
fairly recently (Emmanuel, Gary, others?) to present your 
recollections of
what was difficult, so that we can have a real list of things to try 
and

address.



There is a mini-howto for Commons Math here:
  
https://svn.apache.org/repos/asf/commons/proper/math/trunk/doc/release/release.howto.txt


The aim was to provide a fool-proof, step-by-step recipe, which the 
"official"
Wiki documents were _not_: The missing bits were filled as a summary of 
my

interaction with the ML (cf. archive).
[Luc upgraded the document after the CMS change.]

Nothing is "complicated"; following the recipe should allow anyone to 
make a

release.
As was noted in another post:
 * several steps could be made faster with scripting
 * removing spurious files from Nexus is a pain after a few RCs


Regards,
Gilles


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Emmanuel Bourg]

Le 11/10/2013 01:35, Matt Benson a écrit :
> We're all still talking about the release process, but in all honesty I've
> not done it for several years at Commons.  I think it would be immensely
> helpful for those of us who have been at least part way through the process
> fairly recently (Emmanuel, Gary, others?) to present your recollections of
> what was difficult, so that we can have a real list of things to try and
> address.

Here is my quick feed back on the release process. For the record I
prepared the release on Windows by following the 'Using Nexus for
Commons Maven releases' guide [1]. I also took some bits from the
'Releasing Components' guide [2] (unifying these documents would be a
good start).

1. The initial setup is a bit tedious. Generating the GPG key, uploading
it, configuring the agent, adding the Maven settings. This is not fun
and sometimes frustrating (I didn't set my ASF password properly in the
Maven settings and I had to reset it twice. Nexus rejected my uploads
with a 401 error but I didn't figure my account was locked until I found
myself unable to commit a change in SVN). Hopefully all of this is
performed only once.

2. The Nexus UI is a bit confusing when you are not used to it. Between
User Managed Repositories, Nexus Managed Repositories and Staging
Repositories it wasn't obvious at the first glance to see where the
action was supposed to take place. A mini howto with annotated
screenshots would help.

3. Having to drop manually the -src and -bin artifacts uploaded to Nexus
is annoying. I gave up trying to remove the absurd .asc.sha1 and
.asc.md5 files for JCI, there was too many of them (12 files per
artifact, 6 artifacts).

4. Preparing the release notes is time consuming. I know it can be
generated from JIRA but I don't find that descriptive enough. Using the
Maven changes.xml is the best solution, but it has to be maintained
properly during the development (it wasn't for JCI).

5. I created the tag manually, that was simple enough. I don't trust the
release plugin. I guess I need some training on a dummy project. Due to
minor errors spotted afterward I had to recreate the tag twice. So I
suggest creating the tag only when you have reviewed everything and
about to send the vote mail.

6. 'mvn site:stage-deploy' doesn't work. I got the message
"maven.site.deploy.skip = true: Skipping site deployment". This property
is set in the parent pom! I had to tar the site, upload and install it
manually on people.apache.org.

7. I would like a [VOTE] mail generator :)

8. Uploading the source and the binary archives on people.apache.org
implies too many manual steps. This has to be automated (with a Maven
plugin attached to the deploy phase?).


Emmanuel Bourg

[1] http://wiki.apache.org/commons/UsingNexus
[2] http://commons.apache.org/releases/


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Henri Yandell]

+1 from me for anything that makes the release process sane.

I'd be committing again if preparing a release was simple enough. As it is,
I don't have the blocks of time needed to push out a release and committing
to projects with no apparent release manager becomes an exercise in
futility.

Hen


On Thu, Oct 10, 2013 at 8:24 AM, James Carman wrote:

> Why don't we create a real project that we can cut real releases on to
> test our release procedures?  Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally.  This way, we
> can test out changes to the release process and see how they work.
> Also, a new release manager can play around with that project and get
> it right before diving into the real work.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[Stefan Bodewig]

On 2013-10-11, Matt Benson wrote:

> We're all still talking about the release process, but in all honesty I've
> not done it for several years at Commons.  I think it would be immensely
> helpful for those of us who have been at least part way through the process
> fairly recently (Emmanuel, Gary, others?) to present your recollections of
> what was difficult, so that we can have a real list of things to try and
> address.

Not sure whether May is recent enough :-)

AFAIR there isn't anything difficult.  The major pain point for me is
the sheer number of manual steps - with it comes a big number of
opportunities to make mistakes - and the time it takes.

One detail I just figured out after my third release was that I can
start the gpg-agent before running "mvn deploy" - and I think I've
documented that.  Without that I had to type in my passphrase for every
single artifact.

I prefer the "create the tag manually and avoid the release plugin"
approach but don't think there is a big difference here.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

We're all still talking about the release process, but in all honesty I've
not done it for several years at Commons.  I think it would be immensely
helpful for those of us who have been at least part way through the process
fairly recently (Emmanuel, Gary, others?) to present your recollections of
what was difficult, so that we can have a real list of things to try and
address.

Matt


On Thu, Oct 10, 2013 at 10:46 AM, James Carman
wrote:

> I need to have Matt start writing my emails. What he said! ;)  I'm too
> impatient to be so eloquent.
>
> On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson 
> wrote:
> > Emmanuel,
> >   IMO this goes beyond the SCM question.  Commons releases are painful
> > (you've just been through the process; do you disagree?) and I submit
> that
> > this fact is the reason it takes so long for any of us to muster up the
> > courage to commit himself to diving into that process with no real idea
> > when he'll emerge.  Such a project would allow us to generalize and work
> > out the various "parts" that might be relevant to any Commons project and
> > could then serve as a cookbook to show how to address various situations.
> >
> > Matt
> >
> >
> > On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg 
> wrote:
> >
> >> Le 10/10/2013 17:24, James Carman a écrit :
> >> > Why don't we create a real project that we can cut real releases on to
> >> > test our release procedures?  Perhaps we can set it up so that it
> >> > doesn't sync with central and just gets staged locally.  This way, we
> >> > can test out changes to the release process and see how they work.
> >> > Also, a new release manager can play around with that project and get
> >> > it right before diving into the real work.
> >>
> >> I'm not sure to see the need for this. There is no doubt Git is suitable
> >> for releasing our components. I just walked down the release process for
> >> JCI and besides for tagging I didn't have to interact much with SVN (I
> >> didn't use the Maven release plugin).
> >>
> >> With Git you would just have to create a branch, and push a commit that
> >> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
> >> the same.
> >>
> >> Emmanuel Bourg
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

I need to have Matt start writing my emails. What he said! ;)  I'm too
impatient to be so eloquent.

On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson  wrote:
> Emmanuel,
>   IMO this goes beyond the SCM question.  Commons releases are painful
> (you've just been through the process; do you disagree?) and I submit that
> this fact is the reason it takes so long for any of us to muster up the
> courage to commit himself to diving into that process with no real idea
> when he'll emerge.  Such a project would allow us to generalize and work
> out the various "parts" that might be relevant to any Commons project and
> could then serve as a cookbook to show how to address various situations.
>
> Matt
>
>
> On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg  wrote:
>
>> Le 10/10/2013 17:24, James Carman a écrit :
>> > Why don't we create a real project that we can cut real releases on to
>> > test our release procedures?  Perhaps we can set it up so that it
>> > doesn't sync with central and just gets staged locally.  This way, we
>> > can test out changes to the release process and see how they work.
>> > Also, a new release manager can play around with that project and get
>> > it right before diving into the real work.
>>
>> I'm not sure to see the need for this. There is no doubt Git is suitable
>> for releasing our components. I just walked down the release process for
>> JCI and besides for tagging I didn't have to interact much with SVN (I
>> didn't use the Maven release plugin).
>>
>> With Git you would just have to create a branch, and push a commit that
>> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
>> the same.
>>
>> Emmanuel Bourg
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

Or just a multi-module only and do the worst case scenario.

On Thu, Oct 10, 2013 at 11:41 AM, Emmanuel Bourg  wrote:
> Le 10/10/2013 17:36, James Carman a écrit :
>> This isn't to address Git.  This is just in-general a little sandbox
>> that folks can use to either test out change to the release process
>> (or documentation) or just have a go at being a release manager before
>> actually volunteering.  Anyone would be free to cut a release at any
>> time.
>
> Ah sure, excellent idea. You may want two projects then, a simple one
> and another with modules.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Emmanuel Bourg]

Le 10/10/2013 17:36, James Carman a écrit :
> This isn't to address Git.  This is just in-general a little sandbox
> that folks can use to either test out change to the release process
> (or documentation) or just have a go at being a release manager before
> actually volunteering.  Anyone would be free to cut a release at any
> time.

Ah sure, excellent idea. You may want two projects then, a simple one
and another with modules.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

Emmanuel,
  IMO this goes beyond the SCM question.  Commons releases are painful
(you've just been through the process; do you disagree?) and I submit that
this fact is the reason it takes so long for any of us to muster up the
courage to commit himself to diving into that process with no real idea
when he'll emerge.  Such a project would allow us to generalize and work
out the various "parts" that might be relevant to any Commons project and
could then serve as a cookbook to show how to address various situations.

Matt


On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg  wrote:

> Le 10/10/2013 17:24, James Carman a écrit :
> > Why don't we create a real project that we can cut real releases on to
> > test our release procedures?  Perhaps we can set it up so that it
> > doesn't sync with central and just gets staged locally.  This way, we
> > can test out changes to the release process and see how they work.
> > Also, a new release manager can play around with that project and get
> > it right before diving into the real work.
>
> I'm not sure to see the need for this. There is no doubt Git is suitable
> for releasing our components. I just walked down the release process for
> JCI and besides for tagging I didn't have to interact much with SVN (I
> didn't use the Maven release plugin).
>
> With Git you would just have to create a branch, and push a commit that
> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
> the same.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

This isn't to address Git.  This is just in-general a little sandbox
that folks can use to either test out change to the release process
(or documentation) or just have a go at being a release manager before
actually volunteering.  Anyone would be free to cut a release at any
time.


On Thu, Oct 10, 2013 at 11:34 AM, Emmanuel Bourg  wrote:
> Le 10/10/2013 17:24, James Carman a écrit :
>> Why don't we create a real project that we can cut real releases on to
>> test our release procedures?  Perhaps we can set it up so that it
>> doesn't sync with central and just gets staged locally.  This way, we
>> can test out changes to the release process and see how they work.
>> Also, a new release manager can play around with that project and get
>> it right before diving into the real work.
>
> I'm not sure to see the need for this. There is no doubt Git is suitable
> for releasing our components. I just walked down the release process for
> JCI and besides for tagging I didn't have to interact much with SVN (I
> didn't use the Maven release plugin).
>
> With Git you would just have to create a branch, and push a commit that
> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
> the same.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Emmanuel Bourg]

Le 10/10/2013 17:24, James Carman a écrit :
> Why don't we create a real project that we can cut real releases on to
> test our release procedures?  Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally.  This way, we
> can test out changes to the release process and see how they work.
> Also, a new release manager can play around with that project and get
> it right before diving into the real work.

I'm not sure to see the need for this. There is no doubt Git is suitable
for releasing our components. I just walked down the release process for
JCI and besides for tagging I didn't have to interact much with SVN (I
didn't use the Maven release plugin).

With Git you would just have to create a branch, and push a commit that
changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
the same.

Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

Fine with me!  I'm good with that.  I just was worried folks would
think of it as "cluttering" central


On Thu, Oct 10, 2013 at 11:29 AM, Gary Gregory  wrote:
> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
>  wrote:
>> Why don't we create a real project that we can cut real releases on to
>> test our release procedures?  Perhaps we can set it up so that it
>> doesn't sync with central and just gets staged locally.  This way, we
>> can test out changes to the release process and see how they work.
>> Also, a new release manager can play around with that project and get
>> it right before diving into the real work.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

Once it's properly in Nexus, is there any reason to push all the way to
central?

Matt


On Thu, Oct 10, 2013 at 10:29 AM, Gary Gregory wrote:

> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
>  wrote:
> > Why don't we create a real project that we can cut real releases on to
> > test our release procedures?  Perhaps we can set it up so that it
> > doesn't sync with central and just gets staged locally.  This way, we
> > can test out changes to the release process and see how they work.
> > Also, a new release manager can play around with that project and get
> > it right before diving into the real work.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[Gary Gregory]

Nice idea, but push it to central to test the whole chain.

G

On Thu, Oct 10, 2013 at 11:24 AM, James Carman
 wrote:
> Why don't we create a real project that we can cut real releases on to
> test our release procedures?  Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally.  This way, we
> can test out changes to the release process and see how they work.
> Also, a new release manager can play around with that project and get
> it right before diving into the real work.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[DISCUSS] Creating Project for Release Process Testing...

[James Carman]

Why don't we create a real project that we can cut real releases on to
test our release procedures?  Perhaps we can set it up so that it
doesn't sync with central and just gets staged locally.  This way, we
can test out changes to the release process and see how they work.
Also, a new release manager can play around with that project and get
it right before diving into the real work.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [all] Update release process please

[Matt Benson]

I hope so, as Brian Fox was taking measures to disable the staging area on
mino last week.  :o

Matt


On Thu, Mar 14, 2013 at 12:23 PM, Stefan Bodewig  wrote:

> On 2013-03-14, Gary Gregory wrote:
>
> > In the past, I've have felt (disgusted is too strong a word) discouraged
> > from releasing often by the our release process, and it's a 'process' all
> > right. First, I had started to follow:
>
> > https://commons.apache.org/releases/index.html
>
> > but finding it inadequate, I followed and updated:
>
> > https://wiki.apache.org/commons/UsingNexus
>
> > such that I needed little and then no additional personal cookbook.
>
> Same here.
>
> > Now that we have a new publication process, all of these need updating
> > again, or preferably consolidating into one.
>
> > Can folks who have recently released please update the docs such that it
> > reflects the real world?
>
> I can try (and as always welcome everybody - in particular native
> speakers - to fix all my errors) over the next few days as long as
> memory is fresh.  Mainly I stuck to the UsingNexus workflow.
>
> Can we assume that all components will use Nexus when doing a release by
> now?
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [all] Update release process please

[Stefan Bodewig]

On 2013-03-14, Gary Gregory wrote:

> In the past, I've have felt (disgusted is too strong a word) discouraged
> from releasing often by the our release process, and it's a 'process' all
> right. First, I had started to follow:

> https://commons.apache.org/releases/index.html

> but finding it inadequate, I followed and updated:

> https://wiki.apache.org/commons/UsingNexus

> such that I needed little and then no additional personal cookbook.

Same here.

> Now that we have a new publication process, all of these need updating
> again, or preferably consolidating into one.

> Can folks who have recently released please update the docs such that it
> reflects the real world?

I can try (and as always welcome everybody - in particular native
speakers - to fix all my errors) over the next few days as long as
memory is fresh.  Mainly I stuck to the UsingNexus workflow.

Can we assume that all components will use Nexus when doing a release by
now?

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[henrib]

Hi Jörg;
I've amended the idea based on feedback to *internal* package and @internal
annotation (for pragmatic reasons: a good rule is one which is easy to
follow and enforce). 
The naming convention or the annotation would allow clear but also explicit
boundary; documentation is necessary but not sufficient IMHO. It should be
possible to determine automatically whether "public" code unintentionally
exposes or uses an @internal class by transitivity.
I agree that packaging should be the preferred way but sometimes, it may be
too hard/long/costly to refactor the project; "sprinkling" annotations would
not be ideal but would still allow control over the API stability.
Cheers,
Henrib

PS: We might need @experimental or @beta for APIs intended for public use
but not stable enough to make a hard cast-in-stone stable contract.


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4164209.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Jörg Schaible]

Hi Henri,

henrib wrote:

> 
> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.
> 
> Some of us are looking for very long term/stable/high-quality solutions
> because they need to aggregate lost of components, the stability users.
> Others are looking for best-of-breed/narrow scope/malleable libraries a
> with a guaranteed quality, the usability users.
> Thus the importance of clearly stating in our libraries what is 'stable'
> and what is 'usable'.
> The expressiveness in the language itself is not enough to properly
> describe the contract made regarding each party; i.e. sometimes things
> have to be public but should not be considered part of the API that follow
> the major,minor - deprecation.
> I believe we can come up with a set of agreeable rules to please both
> "camps" be through some naming convention in packages and annotations.
> 
> As an kickstart proposal, may be something as simple as 2 annotations
> actually could be enough: @stable, @usable.
> @stable meaning the contract this API represents will not change without
> being first @deprecated
> @usable meaning this API is valid for this major version but may change in
> each minor with no warning
> We might also use a clear 'internal' sub-package name as a frontier
> delimiter on the same rule.
> 
> Thoughts ?

I don't see a real different between stable and usable. Either a user can 
rely on a functionality or not. If you want to improve a part of the API 
without breaking compatibility, you may always deprecate the part that 
should no longer be used, because it will vanish in the next major release. 
This is what we normally do for a new release. This is e.g. what we've done 
with commons-io (although we improved the interface for generics). If it is 
a real redesign of the API (like lang3), we make it possible to use old and 
new versions side-by-side with new package name and artifactId to avoid 
unresolvable dependency situations for our users.

I am all for 'internal' packages. IMHO it is not necessary to name a package 
as 'internal' as long as it is clearly documented, but it is definitely a 
better indication. It's definitely the right approach to exclude internal 
packages from clirr, personally I'd even exclude internal packages from 
Javadoc. The risc of usage must be clear to every user.

However, I don't believe that annotations will really help. I'd separate 
internal stiff on package boundary and anything else is part of the public 
API. If you start to mix different annotations within one package, all you 
get is confusion.

Cheers,
Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[henrib]

About the *internal* and @internal (package & annotation);
Of course if we could come up with a "binding" convention on the source
layout and package name for all projects, it would be really nice (i.e. the
*internal* package convention). 
(Oh, a common pom where only the source/test/site would be specific and
allow automated reports and release vote publication... just dreaming out
loud)

But as a pragmatist, I'd rather have the @internal annotation that can serve
as an intermediate, easy to use way to determine stability (both for the dev
and the user) than nothing that slows down release cycles to a crawl;
forcing projects to align on a source layout convention is likely bound to
fail or at least a very (very very) long path. 

One of the goal is to allow at least easier - if not faster - release
cycles; as devs, we'd be made easily aware that we are tinkering with the
API contract and for release voting, it gets easier to control that we've
not unintentionally screwed it up.

Oh, and I do agree on the immutability / thread safety doc. :-)
Cheers,
Henrib



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4161225.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Christian Grobmeier]

On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory  wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
> If I upgrade, I am using a new pile of code and I must deal with that.
>
> Using ".internal" packages is an interesting way to go.

It is fine, using annotations is not really a "must have" for me. I
think similar stuff like ".internal" do the Cayenne developers.

> But I do like documentation of some kind for things like immutability and
> thread-safety.

+1

> We've started going down the path of what I call "extreme versioning" when
> we create new packages for new incompatible releases.
>
> Right now, binary incompatible -> new package (I'm even going to include
> Maven artifact ID noise here).
>
> But what about a change in behavior that is not compatible? Should that not
> lead to a new package?

Honestly, no clue.

What do you think on making up some good interfaces for a components.
For example, a "Compress" interface set for version 1. If we decide to
change something, no problem - interfaces stay the same. When the
interfaces change, the version number changes and this will probably
lead to a packagename change.

I would hate to see o.a.c.compress_2_1.bla btw. ;-)

> Commons is a 'special' project because it includes so many components. It
> would be nice if all components played by the same rules. Strictly
> speaking, I think we are bound to do so.

Very much +1. There are so many differences. As a user I am totally
lost on all the different things people do.

Cheers

>
> Gary
>
> On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier 
> wrote:
>
>> Henri,
>>
>> I would love to see this as a Commons recommendation on the Wiki.
>> As Stefan mentioned, in Compress we have @experimental annons (I
>> actually added them).
>> I like the idea to make up a public, rarely to break interface api and
>> some not so public sometimes to break implementation. Maybe we should
>> even consider to create an interface jar and an implementation jar of
>> different versions. On the other hand this makes things complex - but
>> anyway
>>
>> Cheers
>> Christian
>>
>> On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
>> > Keeping track as it evolves based on feedback;
>> >
>> > Goal is to allow easy definition, usage and check of stable APIs.
>> > An annotation and a package naming convention allow the project
>> developer to
>> > clearly state when a class/method/field is not part of the stable
>> contract
>> > despite a public/protected declaration but only of the internal part of
>> the
>> > project.
>> >
>> > @internal annotated class/method or *internal* package mean "use this at
>> > your own maintenance cost"; those are not part of the "public" API. They
>> can
>> > be used and extended but are subject to change between versions without
>> > @deprecated annotations.
>> >
>> > Those annotations and conventions should allow feeding a clirr report
>> with
>> > the proper information to allow detection of unintended API breakage and
>> may
>> > even allow creating IDE plugins to warn about usage.
>> >
>> > --
>> > View this message in context:
>> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html
>> > Sent from the Commons - Dev mailing list archive at Nabble.com.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[sebb]

On 5 December 2011 15:42, Gary Gregory  wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.

If your component is part of a larger application that may not be
true, see below.

> If I upgrade, I am using a new pile of code and I must deal with that.

That's OK if your code is stand-alone at the end of the food chain,
and you have control over it.

Commons components often are deeply embedded.

> Using ".internal" packages is an interesting way to go.
>
> But I do like documentation of some kind for things like immutability and
> thread-safety.
>
> We've started going down the path of what I call "extreme versioning" when
> we create new packages for new incompatible releases.
>
> Right now, binary incompatible -> new package (I'm even going to include
> Maven artifact ID noise here).

See below for the reason why that is generally necessary.

> But what about a change in behavior that is not compatible? Should that not
> lead to a new package?

Depends why the behaviour changed. Is it a bug fix?

> Commons is a 'special' project because it includes so many components. It
> would be nice if all components played by the same rules. Strictly
> speaking, I think we are bound to do so.

I would say the Commons components are special because they are likely
to be deeply nested in applications, with many other components
depending on them.

It may not be possible to upgrade the other components all at once.
Some may be impossible to replace.
If two components in the same classpath need incompatible versions, it
will in general be impossible to update unless the two versions can
coexist.

That is why we have the rules on package/Maven id changes, so there
can be multiple versions of a Commons component on the same classpath,
if the need arises.

Because package changes are expensive to end users, we try to avoid
them if at all possible.

That is why it's worth striving for binary compatibility.

> Gary
>
> On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier 
> wrote:
>
>> Henri,
>>
>> I would love to see this as a Commons recommendation on the Wiki.
>> As Stefan mentioned, in Compress we have @experimental annons (I
>> actually added them).
>> I like the idea to make up a public, rarely to break interface api and
>> some not so public sometimes to break implementation. Maybe we should
>> even consider to create an interface jar and an implementation jar of
>> different versions. On the other hand this makes things complex - but
>> anyway
>>
>> Cheers
>> Christian
>>
>> On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
>> > Keeping track as it evolves based on feedback;
>> >
>> > Goal is to allow easy definition, usage and check of stable APIs.
>> > An annotation and a package naming convention allow the project
>> developer to
>> > clearly state when a class/method/field is not part of the stable
>> contract
>> > despite a public/protected declaration but only of the internal part of
>> the
>> > project.
>> >
>> > @internal annotated class/method or *internal* package mean "use this at
>> > your own maintenance cost"; those are not part of the "public" API. They
>> can
>> > be used and extended but are subject to change between versions without
>> > @deprecated annotations.
>> >
>> > Those annotations and conventions should allow feeding a clirr report
>> with
>> > the proper information to allow detection of unintended API breakage and
>> may
>> > even allow creating IDE plugins to warn about usage.
>> >
>> > --
>> > View this message in context:
>> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html
>> > Sent from the Commons - Dev mailing list archive at Nabble.com.
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Simone Tripodi]

Hi Gary!

On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory  wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
> If I upgrade, I am using a new pile of code and I must deal with that.
>
> Using ".internal" packages is an interesting way to go.
>

interesting stuff as well - I learnt a trick from Google Guice team
that developed internal stuff only[1] and then "obfuscate"[2] them in
the way most ides won't recognize for code completion, so users cannot
rely on internal APIs :P
I personally think that is a valid approach, just my 0.02 cents,
-Simo

[1] http://s.apache.org/dt7
[2] http://s.apache.org/yC

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Gary Gregory]

Personally, I do not like annotations to describe the stability of an API.

If it's public I can use it. The next release is binary and/or source
compatible, just document how to migrate. No one is forcing me to upgrade.
If I upgrade, I am using a new pile of code and I must deal with that.

Using ".internal" packages is an interesting way to go.

But I do like documentation of some kind for things like immutability and
thread-safety.

We've started going down the path of what I call "extreme versioning" when
we create new packages for new incompatible releases.

Right now, binary incompatible -> new package (I'm even going to include
Maven artifact ID noise here).

But what about a change in behavior that is not compatible? Should that not
lead to a new package?

Commons is a 'special' project because it includes so many components. It
would be nice if all components played by the same rules. Strictly
speaking, I think we are bound to do so.

Gary

On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier wrote:

> Henri,
>
> I would love to see this as a Commons recommendation on the Wiki.
> As Stefan mentioned, in Compress we have @experimental annons (I
> actually added them).
> I like the idea to make up a public, rarely to break interface api and
> some not so public sometimes to break implementation. Maybe we should
> even consider to create an interface jar and an implementation jar of
> different versions. On the other hand this makes things complex - but
> anyway
>
> Cheers
> Christian
>
> On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
> > Keeping track as it evolves based on feedback;
> >
> > Goal is to allow easy definition, usage and check of stable APIs.
> > An annotation and a package naming convention allow the project
> developer to
> > clearly state when a class/method/field is not part of the stable
> contract
> > despite a public/protected declaration but only of the internal part of
> the
> > project.
> >
> > @internal annotated class/method or *internal* package mean "use this at
> > your own maintenance cost"; those are not part of the "public" API. They
> can
> > be used and extended but are subject to change between versions without
> > @deprecated annotations.
> >
> > Those annotations and conventions should allow feeding a clirr report
> with
> > the proper information to allow detection of unintended API breakage and
> may
> > even allow creating IDE plugins to warn about usage.
> >
> > --
> > View this message in context:
> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html
> > Sent from the Commons - Dev mailing list archive at Nabble.com.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [RELEASE PROCESS] Stability versus usability

[Simone Tripodi]

+1 Christian this is a nice idea - maybe RetentionPolicy.SOURCE
annotations? (so we don't have to bring the dependency in each
component for runtime...)
Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 4:21 PM, Christian Grobmeier  wrote:
> Henri,
>
> I would love to see this as a Commons recommendation on the Wiki.
> As Stefan mentioned, in Compress we have @experimental annons (I
> actually added them).
> I like the idea to make up a public, rarely to break interface api and
> some not so public sometimes to break implementation. Maybe we should
> even consider to create an interface jar and an implementation jar of
> different versions. On the other hand this makes things complex - but
> anyway
>
> Cheers
> Christian
>
> On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
>> Keeping track as it evolves based on feedback;
>>
>> Goal is to allow easy definition, usage and check of stable APIs.
>> An annotation and a package naming convention allow the project developer to
>> clearly state when a class/method/field is not part of the stable contract
>> despite a public/protected declaration but only of the internal part of the
>> project.
>>
>> @internal annotated class/method or *internal* package mean "use this at
>> your own maintenance cost"; those are not part of the "public" API. They can
>> be used and extended but are subject to change between versions without
>> @deprecated annotations.
>>
>> Those annotations and conventions should allow feeding a clirr report with
>> the proper information to allow detection of unintended API breakage and may
>> even allow creating IDE plugins to warn about usage.
>>
>> --
>> View this message in context: 
>> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Christian Grobmeier]

Henri,

I would love to see this as a Commons recommendation on the Wiki.
As Stefan mentioned, in Compress we have @experimental annons (I
actually added them).
I like the idea to make up a public, rarely to break interface api and
some not so public sometimes to break implementation. Maybe we should
even consider to create an interface jar and an implementation jar of
different versions. On the other hand this makes things complex - but
anyway

Cheers
Christian

On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
> Keeping track as it evolves based on feedback;
>
> Goal is to allow easy definition, usage and check of stable APIs.
> An annotation and a package naming convention allow the project developer to
> clearly state when a class/method/field is not part of the stable contract
> despite a public/protected declaration but only of the internal part of the
> project.
>
> @internal annotated class/method or *internal* package mean "use this at
> your own maintenance cost"; those are not part of the "public" API. They can
> be used and extended but are subject to change between versions without
> @deprecated annotations.
>
> Those annotations and conventions should allow feeding a clirr report with
> the proper information to allow detection of unintended API breakage and may
> even allow creating IDE plugins to warn about usage.
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[sebb]

On 4 December 2011 10:41, henrib  wrote:
> Keeping track as it evolves based on feedback;
>
> Goal is to allow easy definition, usage and check of stable APIs.

+1, agree that we need to be clearer about what the intended external API is.

> An annotation and a package naming convention allow the project developer to
> clearly state when a class/method/field is not part of the stable contract
> despite a public/protected declaration but only of the internal part of the
> project.

+1

> @internal annotated class/method or *internal* package mean "use this at
> your own maintenance cost"; those are not part of the "public" API. They can
> be used and extended but are subject to change between versions without
> @deprecated annotations.

+1.

I prefer the use of a separate internal/experimental package name;
seems much more obvious than an embedded annotation.
Also much more obvious when setting up Clirr exclusions.

I think it's worth having both internal and experimental packages (and
annotations):
- internal = not likely ever to be part of the external API
- experimental = may one day become part of the external API

However, I'm not yet sure how we get around the binary
incompatibilities that result from renaming a package to internal or
experimental (the reverse should be OK, as we don't promise anything)

> Those annotations and conventions should allow feeding a clirr report with
> the proper information to allow detection of unintended API breakage and may
> even allow creating IDE plugins to warn about usage.

Clirr can already be told to ignore packages and classes.
If it were possible to control this via annotations, I would hope that
the report would show which classes had been excluded from
consideration.
At least with explicit exclusions in the POM it's fairly easy to see
this information in one place.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[henrib]

Keeping track as it evolves based on feedback;

Goal is to allow easy definition, usage and check of stable APIs.
An annotation and a package naming convention allow the project developer to
clearly state when a class/method/field is not part of the stable contract
despite a public/protected declaration but only of the internal part of the
project.

@internal annotated class/method or *internal* package mean "use this at
your own maintenance cost"; those are not part of the "public" API. They can
be used and extended but are subject to change between versions without
@deprecated annotations.

Those annotations and conventions should allow feeding a clirr report with
the proper information to allow detection of unintended API breakage and may
even allow creating IDE plugins to warn about usage.

--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[henrib]

ralph.goers @dslextreme.com wrote
> 
> The part I'm struggling with is that if these are annotations vs just
> javadoc tags then I would expect some kind of either compile time or
> runtime behavior (or both).  It seems that you are proposing javadoc tags
> instead?  If not what behavior would the annotations cause?
> 
I'm not versed enough in Javadoc but I believe annotation carry more
processing "power". The information can remain in the executable and allow
post build analysis. To feed a clirr report, it seems we'd need to
introspect the classes/methods to find those @internal. One could even dream
of a -your favorite IDE here- plugin that warns you when using one of those.
If there is an easy / easier practical solution that could serve the same
purpose, I'm all for it!


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156415.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[henrib]

Stefan Bodewig wrote
> 
> Would you have known at the point when JEXL 2.0.1 has been released
> which APIs you'd mark up as @stable or @usable?
> 
Yes for most and in doubt, I could have marked them @usable (or @internal
which may be a better term).


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156394.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Stefan Bodewig]

On 2011-12-04, henrib wrote:

> When trying to release JEXL 2.1, the API was disrupted and the clirr report
> was outputing lots of clutter.
> As the dev, it became very hard to understand whether the change was
> actually breaking the intended stable API or just some internal methods or
> class.

Would you have known at the point when JEXL 2.0.1 has been released
which APIs you'd mark up as @stable or @usable?

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Ralph Goers]

The part I'm struggling with is that if these are annotations vs just javadoc 
tags then I would expect some kind of either compile time or runtime behavior 
(or both).  It seems that you are proposing javadoc tags instead?  If not what 
behavior would the annotations cause?

Ralph

On Dec 3, 2011, at 5:22 PM, Phil Steitz wrote:

> On 12/2/11 3:45 PM, henrib wrote:
>> It seems to me we have a hard time allowing both stability and usability.
>> Stability of APIs does not contradict usability of the library, at least
>> should not.
>> 
>> Some of us are looking for very long term/stable/high-quality solutions
>> because they need to aggregate lost of components, the stability users.
>> Others are looking for best-of-breed/narrow scope/malleable libraries a with
>> a guaranteed quality, the usability users.
>> Thus the importance of clearly stating in our libraries what is 'stable' and
>> what is 'usable'.
>> The expressiveness in the language itself is not enough to properly describe
>> the contract made regarding each party; i.e. sometimes things have to be
>> public but should not be considered part of the API that follow the
>> major,minor - deprecation.
>> I believe we can come up with a set of agreeable rules to please both
>> "camps" be through some naming convention in packages and annotations.
>> 
>> As an kickstart proposal, may be something as simple as 2 annotations
>> actually could be enough: @stable, @usable.
>> @stable meaning the contract this API represents will not change without
>> being first @deprecated
>> @usable meaning this API is valid for this major version but may change in
>> each minor with no warning
>> We might also use a clear 'internal' sub-package name as a frontier
>> delimiter on the same rule.
>> 
>> Thoughts ?
> 
> I applaud the initiative and creative suggestion above.  I wonder,
> though, what users would make of it.  My first thought as a user
> would be to avoid ever using the "unstable" stuff but I can imagine
> scenarios where I might. 
> 
> In practical terms, it might be hard to decide what to put where. 
> Can you provide some examples based on recent RCs?
> 
> An easy baby step that I could personally get behind - and actually
> need in [math] - is adopting the .internal package name convention
> for classes that need to be public because they are used in multiple
> packages, but which are not intended for use by external
> applications and effectively exempt from version compatibility
> requirements.  That could by itself provide a workaround for a lot
> of these issues.
> 
> Phil
>> Best regards,
>> Henri
>> 
>> --
>> View this message in context: 
>> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[henrib]

Phil Steitz wrote
> 
> In practical terms, it might be hard to decide what to put where. 
> Can you provide some examples based on recent RCs?
> 
When trying to release JEXL 2.1, the API was disrupted and the clirr report
was outputing lots of clutter.
As the dev, it became very hard to understand whether the change was
actually breaking the intended stable API or just some internal methods or
class. Then a lot of effort - thanks to sebb - had to be spent just to check
and amend the code to restore the contract.
The findbugs, cobertura, chekstyle reports mostly allow to assess quality, a
"usable" clirr report would give us a good view of "stability".

Phil Steitz wrote
> 
> An easy baby step that I could personally get behind - and actually
> need in [math] - is adopting the .internal package name convention
> 
For new packages or during major code overhaul, it definitely does the job.
But it might be unpractical and requires lots of code moving around; I'm
currently trying to achieve this with JEXL3 and it is a major refactor. Plus
it requires creating interfaces or abstract classes to clearly delineate the
API; it tilts the balance of effort towards stability and hinders the
ability to add features (in the same timeframe) thus slows down innovation.
The annotation would be convenient to (re)decorate code since it is very
lightweight, easy to use and control.
Instead of @unstable / @usable, may be an @internal annotation would carry
the proper information and would follow the same idea as the package name. 

@internal annotated class/method or *internal* package mean "use this at
your own maintenance cost"; it still allows "users" to code using them, does
not forcibly close extensibility thus preserve innovative contributions and
provides a clearer view of the stable contract. Seems like a win-win.

Best regards,
Henrib



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156330.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Stefan Bodewig]

On 2011-12-02, henrib wrote:

> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.

I'm glad you say that right at the beginning as the "versus" in the
subject line seems to imply something else. 8-)

> Some of us are looking for very long term/stable/high-quality solutions
> because they need to aggregate lost of components, the stability users.
> Others are looking for best-of-breed/narrow scope/malleable libraries a with
> a guaranteed quality, the usability users.

[Aside: is best-of-breed really impossible in a stable environment?]

I don't think this is all there is to it.

As one of the few people who still see value in Gump I tend to be in the
stability camp - if there really are only these two choices.  But it is
more about the impact a new release has on the users than the number of
components anybody aggregates.  I don't think anybody likes the idea of
having to modify code every time you update your dependencies.

> Thus the importance of clearly stating in our libraries what is
> 'stable' and what is 'usable'.

While I like the idea to explicitly mark what you consider a
stable/reliable API I don't think I like the tags.  Or at least the tag
"usable".  That it implies the "stable" parts are not usable makes me
itch.

> As an kickstart proposal, may be something as simple as 2 annotations
> actually could be enough: @stable, @usable.
> @stable meaning the contract this API represents will not change without
> being first @deprecated
> @usable meaning this API is valid for this major version but may change in
> each minor with no warning
> We might also use a clear 'internal' sub-package name as a frontier
> delimiter on the same rule.

Maybe we actually have three sorts of public APIs

* APIs that we promise not to break unless we perform a major relase in
  which case we also change package names (and artifactIds).  This is
  what you call @stable.

* APIs that may break in minor releases.  What you call @usable

  There is some danger to it in that you mark too many parts unstable
  and forget about them.  I really think users prefer stable APIs to
  begin with unless the unstable ones offer important features and
  promise to become stable at one point in time.

  Compress has a package that has *experimental* warnings in Javadocs
  all over the place.  It has carried this label for four minor relases
  now.  Is it still experimental?  I think anything not @stable needs to
  be revisited from time to time.

* APIs that are only public for technical reasons but really are
  internal to the component.  I think these are different from what you
  call @usable.  And these should be allowed to change without warning
  as long as users are aware of the policy.

So yes, I understand and agree that we sometimes want to add features
and push them out to users before we understand them well enough to
provide a stable API.  And I really welcome any approach of explicitly
marking those parts so that users - and people reviewing releases - know
what to expect.  But I also think the non-stable APIs have to be
reconsidered from time to time and eventually become stable.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Bruno P. Kinoshita]

>I applaud the initiative and creative suggestion above.  I wonder,
>though, what users would make of it.  My first thought as a user
>would be to avoid ever using the "unstable" stuff but I can imagine
>scenarios where I might. 


Hi, 


I was wondering the same thing, from a user perspective too. I would avoid 
using the unstable classes too, and would like to have a way to know if any 
unstable classes are being used in one of my projects :)


Having a quick glance on clirr maven plug-in site, I couldn't find much about 
its configuration. What if instead of adding these annotations, we suggested 
this as configuration to clirr? This way, instead of using annotations, we 
would use something similar to:


    
        org.apache

    



And clirr wouldn't report on classes not listed in the configuration.


Just food for thought :-)

Cheers,

 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com



 De: Phil Steitz 
Para: Commons Developers List  
Enviadas: Sábado, 3 de Dezembro de 2011 23:22
Assunto: Re: [RELEASE PROCESS] Stability versus usability
 
On 12/2/11 3:45 PM, henrib wrote:
> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.
>
> Some of us are looking for very long term/stable/high-quality solutions
> because they need to aggregate lost of components, the stability users.
> Others are looking for best-of-breed/narrow scope/malleable libraries a with
> a guaranteed quality, the usability users.
> Thus the importance of clearly stating in our libraries what is 'stable' and
> what is 'usable'.
> The expressiveness in the language itself is not enough to properly describe
> the contract made regarding each party; i.e. sometimes things have to be
> public but should not be considered part of the API that follow the
> major,minor - deprecation.
> I believe we can come up with a set of agreeable rules to please both
> "camps" be through some naming convention in packages and annotations.
>
> As an kickstart proposal, may be something as simple as 2 annotations
> actually could be enough: @stable, @usable.
> @stable meaning the contract this API represents will not change without
> being first @deprecated
> @usable meaning this API is valid for this major version but may change in
> each minor with no warning
> We might also use a clear 'internal' sub-package name as a frontier
> delimiter on the same rule.
>
> Thoughts ?

I applaud the initiative and creative suggestion above.  I wonder,
though, what users would make of it.  My first thought as a user
would be to avoid ever using the "unstable" stuff but I can imagine
scenarios where I might. 

In practical terms, it might be hard to decide what to put where. 
Can you provide some examples based on recent RCs?

An easy baby step that I could personally get behind - and actually
need in [math] - is adopting the .internal package name convention
for classes that need to be public because they are used in multiple
packages, but which are not intended for use by external
applications and effectively exempt from version compatibility
requirements.  That could by itself provide a workaround for a lot
of these issues.

Phil
> Best regards,
> Henri
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[Phil Steitz]

On 12/2/11 3:45 PM, henrib wrote:
> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.
>
> Some of us are looking for very long term/stable/high-quality solutions
> because they need to aggregate lost of components, the stability users.
> Others are looking for best-of-breed/narrow scope/malleable libraries a with
> a guaranteed quality, the usability users.
> Thus the importance of clearly stating in our libraries what is 'stable' and
> what is 'usable'.
> The expressiveness in the language itself is not enough to properly describe
> the contract made regarding each party; i.e. sometimes things have to be
> public but should not be considered part of the API that follow the
> major,minor - deprecation.
> I believe we can come up with a set of agreeable rules to please both
> "camps" be through some naming convention in packages and annotations.
>
> As an kickstart proposal, may be something as simple as 2 annotations
> actually could be enough: @stable, @usable.
> @stable meaning the contract this API represents will not change without
> being first @deprecated
> @usable meaning this API is valid for this major version but may change in
> each minor with no warning
> We might also use a clear 'internal' sub-package name as a frontier
> delimiter on the same rule.
>
> Thoughts ?

I applaud the initiative and creative suggestion above.  I wonder,
though, what users would make of it.  My first thought as a user
would be to avoid ever using the "unstable" stuff but I can imagine
scenarios where I might. 

In practical terms, it might be hard to decide what to put where. 
Can you provide some examples based on recent RCs?

An easy baby step that I could personally get behind - and actually
need in [math] - is adopting the .internal package name convention
for classes that need to be public because they are used in multiple
packages, but which are not intended for use by external
applications and effectively exempt from version compatibility
requirements.  That could by itself provide a workaround for a lot
of these issues.

Phil
> Best regards,
> Henri
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RELEASE PROCESS] Stability versus usability

[henrib]

Since it may need clarification;

The idea would be to allow a clirr report to give accurate analysis of
whether the external / stable API has been modified.
Methods or classes annotated as @stable, could not change from one version
to another before they are @deprecated.
Methods or classes annotated as @unstable (rather than @usable) could change
between versions.

The net result would be a good sense of whether the actual stable API is
broken by a version and avoid lengthy discussions like the one we just
had...

Wouldn't this be possible to add to our toolbox as a clirr plugin of some
kind?



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4154703.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[RELEASE PROCESS] Stability versus usability

[henrib]

It seems to me we have a hard time allowing both stability and usability.
Stability of APIs does not contradict usability of the library, at least
should not.

Some of us are looking for very long term/stable/high-quality solutions
because they need to aggregate lost of components, the stability users.
Others are looking for best-of-breed/narrow scope/malleable libraries a with
a guaranteed quality, the usability users.
Thus the importance of clearly stating in our libraries what is 'stable' and
what is 'usable'.
The expressiveness in the language itself is not enough to properly describe
the contract made regarding each party; i.e. sometimes things have to be
public but should not be considered part of the API that follow the
major,minor - deprecation.
I believe we can come up with a set of agreeable rules to please both
"camps" be through some naming convention in packages and annotations.

As an kickstart proposal, may be something as simple as 2 annotations
actually could be enough: @stable, @usable.
@stable meaning the contract this API represents will not change without
being first @deprecated
@usable meaning this API is valid for this major version but may change in
each minor with no warning
We might also use a clear 'internal' sub-package name as a frontier
delimiter on the same rule.

Thoughts ?
Best regards,
Henri

--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Simone Tripodi]

shall I have to open an Issue so it does?

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, May 2, 2011 at 8:19 PM, Jochen Wiedmann
 wrote:
> On Mon, May 2, 2011 at 2:26 PM, Simone Tripodi  
> wrote:
>
>> I don't think (bin|src)-(.zip|.tar.gz) should be part of Maven
>> artifacts on central repo, having them on the distribution servers is
>> enough
>
> "I don't think" doesn't count as a problem that ought to be fixed, isn't it?
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Jochen Wiedmann]

On Mon, May 2, 2011 at 2:26 PM, Simone Tripodi  wrote:

> I don't think (bin|src)-(.zip|.tar.gz) should be part of Maven
> artifacts on central repo, having them on the distribution servers is
> enough

"I don't think" doesn't count as a problem that ought to be fixed, isn't it?


-- 
I Am What I Am And That's All What I Yam (Popeye)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Simone Tripodi]

I don't think (bin|src)-(.zip|.tar.gz) should be part of Maven
artifacts on central repo, having them on the distribution servers is
enough

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, May 2, 2011 at 1:12 PM, Jochen Wiedmann
 wrote:
> On Sun, May 1, 2011 at 3:55 PM, Simone Tripodi  
> wrote:
>
>> Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
>> been copied to be sync'ed to central repo :'(
>
> So what? I think that's perfectly fine.
>
>
> --
> I Am What I Am And That's All What I Yam (Popeye)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Jochen Wiedmann]

On Sun, May 1, 2011 at 3:55 PM, Simone Tripodi  wrote:

> Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
> been copied to be sync'ed to central repo :'(

So what? I think that's perfectly fine.


-- 
I Am What I Am And That's All What I Yam (Popeye)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Jochen Wiedmann]

On Sun, May 1, 2011 at 12:53 PM, Simone Tripodi
 wrote:

> I just realized that maybe artifacts produced by the assembly plugin
> should not be attached[1], WDYT?

In contrary, they should, to make use of all the Maven plugins for signing etc.



-- 
I Am What I Am And That's All What I Yam (Popeye)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Phil Steitz]

On 5/1/11 9:18 AM, Simone Tripodi wrote:
> Thanks *a lot* Phil for your kind help.
> I just executed the commands you suggested me, and dopped *tar.gz*
> *zip* files, original are still on staged[1] repository
> Looking forward to see Discovery synched!!!
> Have a nice day,
> Simo
>
> [1] 
> http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/commons-discovery/commons-discovery/0.5/
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
Great.  Files and perms look good.  If the synch still have not
happened in a few more hours, ping repository@
 
Phil
> On Sun, May 1, 2011 at 6:04 PM, Phil Steitz  wrote:
>> On 5/1/11 6:55 AM, Simone Tripodi wrote:
>>> Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
>>> been copied to be sync'ed to central repo :'(
>>> does someone have an idea how to remove them?
>> I just tried to move the zips and tarballs to my home directory, but
>> could not because the files were not group writeable  This may also
>> cause problems for the rsynch.  You need to log into p.a.o and then
>>
>> cd
>> /www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-discovery/commons-discovery/0.5/
>> chmod g+w *
>>
>> Then either delete or move the zips, tarballs and associated hashes
>> and sigs.
>>
>> Phil
>>> Thanks in advance,
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg  wrote:
 Le 01/05/2011 12:53, Simone Tripodi a écrit :
> Hi again,
> I just realized that maybe artifacts produced by the assembly plugin
> should not be attached[1], WDYT?
> Simo
 I agree. This is not the case already?

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Simone Tripodi]

Thanks *a lot* Phil for your kind help.
I just executed the commands you suggested me, and dopped *tar.gz*
*zip* files, original are still on staged[1] repository
Looking forward to see Discovery synched!!!
Have a nice day,
Simo

[1] 
http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/commons-discovery/commons-discovery/0.5/

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, May 1, 2011 at 6:04 PM, Phil Steitz  wrote:
> On 5/1/11 6:55 AM, Simone Tripodi wrote:
>> Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
>> been copied to be sync'ed to central repo :'(
>> does someone have an idea how to remove them?
>
> I just tried to move the zips and tarballs to my home directory, but
> could not because the files were not group writeable  This may also
> cause problems for the rsynch.  You need to log into p.a.o and then
>
> cd
> /www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-discovery/commons-discovery/0.5/
> chmod g+w *
>
> Then either delete or move the zips, tarballs and associated hashes
> and sigs.
>
> Phil
>> Thanks in advance,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg  wrote:
>>> Le 01/05/2011 12:53, Simone Tripodi a écrit :
 Hi again,
 I just realized that maybe artifacts produced by the assembly plugin
 should not be attached[1], WDYT?
 Simo
>>> I agree. This is not the case already?
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Phil Steitz]

On 5/1/11 6:55 AM, Simone Tripodi wrote:
> Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
> been copied to be sync'ed to central repo :'(
> does someone have an idea how to remove them?

I just tried to move the zips and tarballs to my home directory, but
could not because the files were not group writeable  This may also
cause problems for the rsynch.  You need to log into p.a.o and then

cd
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-discovery/commons-discovery/0.5/
chmod g+w *

Then either delete or move the zips, tarballs and associated hashes
and sigs.

Phil
> Thanks in advance,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg  wrote:
>> Le 01/05/2011 12:53, Simone Tripodi a écrit :
>>> Hi again,
>>> I just realized that maybe artifacts produced by the assembly plugin
>>> should not be attached[1], WDYT?
>>> Simo
>> I agree. This is not the case already?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Phil Steitz]

On 5/1/11 6:55 AM, Simone Tripodi wrote:
> Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
> been copied to be sync'ed to central repo :'(
> does someone have an idea how to remove them?
> Thanks in advance,
> Simo

I assume they have been *copied* not moved, right?  So there is no
risk in deleting them?

In that case, you can just ssh to p.a.o and then delete the files
manually from
/www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-discovery/commons-discovery/0.5/

Let me know if you have problems and I will to this.  I didn't want
to do the deletes myself until you confirmed that what you / the
plugin did was a copy so you still have the originals to move to
dist/ somewhere.

Phil

> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg  wrote:
>> Le 01/05/2011 12:53, Simone Tripodi a écrit :
>>> Hi again,
>>> I just realized that maybe artifacts produced by the assembly plugin
>>> should not be attached[1], WDYT?
>>> Simo
>> I agree. This is not the case already?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Phil Steitz]

On 5/1/11 7:58 AM, Simone Tripodi wrote:
> Moreover, after 4 hours the central has not been synched yet... are
> you aware of any issue?

It often takes quite a while, but it looks like commons-discovery
may not have yet been synched from m2-ibiblio-rsych, so you may need
to send a request to repository@ to get it set up for rsynch.  I
would wait a few more hours and then do that.

Phil
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, May 1, 2011 at 3:55 PM, Simone Tripodi  
> wrote:
>> Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
>> been copied to be sync'ed to central repo :'(
>> does someone have an idea how to remove them?
>> Thanks in advance,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg  wrote:
>>> Le 01/05/2011 12:53, Simone Tripodi a écrit :
 Hi again,
 I just realized that maybe artifacts produced by the assembly plugin
 should not be attached[1], WDYT?
 Simo
>>> I agree. This is not the case already?
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Simone Tripodi]

Moreover, after 4 hours the central has not been synched yet... are
you aware of any issue?
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, May 1, 2011 at 3:55 PM, Simone Tripodi  wrote:
> Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
> been copied to be sync'ed to central repo :'(
> does someone have an idea how to remove them?
> Thanks in advance,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg  wrote:
>> Le 01/05/2011 12:53, Simone Tripodi a écrit :
>>>
>>> Hi again,
>>> I just realized that maybe artifacts produced by the assembly plugin
>>> should not be attached[1], WDYT?
>>> Simo
>>
>> I agree. This is not the case already?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Simone Tripodi]

Yes it is :( Problem is that for discovery-0.5, zip and tar.gz have
been copied to be sync'ed to central repo :'(
does someone have an idea how to remove them?
Thanks in advance,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, May 1, 2011 at 2:19 PM, Emmanuel Bourg  wrote:
> Le 01/05/2011 12:53, Simone Tripodi a écrit :
>>
>> Hi again,
>> I just realized that maybe artifacts produced by the assembly plugin
>> should not be attached[1], WDYT?
>> Simo
>
> I agree. This is not the case already?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Emmanuel Bourg]

Le 01/05/2011 12:53, Simone Tripodi a écrit :

Hi again,
I just realized that maybe artifacts produced by the assembly plugin
should not be attached[1], WDYT?
Simo


I agree. This is not the case already?

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [release process] zip and tar.gz included in maven repo?

[Simone Tripodi]

Hi again,
I just realized that maybe artifacts produced by the assembly plugin
should not be attached[1], WDYT?
Simo

[1] 
http://maven.apache.org/plugins/maven-assembly-plugin/single-mojo.html#attach

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, May 1, 2011 at 12:38 PM, Simone Tripodi
 wrote:
> Hi all guys,
> while copying maven artifacts as described in the wiki page[1] using
> the command below, I noticed .zip and .tar.gz artifacts are included
> :/
> Is this right? I wouldn't say 'no' but maybe I missed something.
> Moreover, the command doesn't work with M3 because the missing
> wagon-ssh extension.
> Do you have any suggestion to complete correctly the release process?
> Thanks in advance!
> Simo
>
> mvn stage:copy 
> -Dsource="http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/";
> \
>  -Dtarget="scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository"
> \
>  -DtargetRepositoryId=apache.releases \
>  -Dversion=0.5
>
> [1] http://wiki.apache.org/commons/CreatingReleases (see E.2 Copy
> Artifacts from Staging)
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[release process] zip and tar.gz included in maven repo?

[Simone Tripodi]

Hi all guys,
while copying maven artifacts as described in the wiki page[1] using
the command below, I noticed .zip and .tar.gz artifacts are included
:/
Is this right? I wouldn't say 'no' but maybe I missed something.
Moreover, the command doesn't work with M3 because the missing
wagon-ssh extension.
Do you have any suggestion to complete correctly the release process?
Thanks in advance!
Simo

mvn stage:copy 
-Dsource="http://people.apache.org/builds/commons/discovery/0.5/RC2/staged/";
\
  
-Dtarget="scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository"
\
  -DtargetRepositoryId=apache.releases \
  -Dversion=0.5

[1] http://wiki.apache.org/commons/CreatingReleases (see E.2 Copy
Artifacts from Staging)

http://people.apache.org/~simonetripodi/
http://www.99soft.org/

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Passwords in Maven settings file [Was: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1]

[Henri Yandell]

On Tue, Apr 5, 2011 at 2:37 AM, sebb  wrote:
> On 5 April 2011 09:32, Jochen Wiedmann  wrote:
>> On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell  wrote:
>>
>>> [Side note; this is insane:
>>> http://maven.apache.org/guides/mini/guide-encryption.html - I vomit
>>> every time it's implied I should put passwords in the Maven settings
>>> file]
>>
>> Totally agreed!
>
> There are a couple of ways around that.
>
> 1) Use settings-security.xml  to store the real
> settings-security.xml on a removable device.

Vomiting more :) At least I know when I physically lose my laptop.

The docs also need to be pushing "encrypted removable device" more.
It's taken as read that people will do that.

> 2) It would be nice if Maven supported a keyserver of some kind (cf.
> Pageant for Putty), but it does not. However one can use the
>  element to point to a server that returns the passwords.
> I wrote a Java app that acts as a simple keyserver; of course that
> needs its own password.
>
> If the device is not present, or the server is not running, you get a
> warning message when starting Maven builds.
> [When using the keyserver I normally give it a dummy password, as that
> avoids the time delay when Maven looks for the server; however one
> still gets warnings]

Entering at the command line is fine for me. :)

Hen

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Passwords in Maven settings file [Was: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1]

[sebb]

On 5 April 2011 09:32, Jochen Wiedmann  wrote:
> On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell  wrote:
>
>> [Side note; this is insane:
>> http://maven.apache.org/guides/mini/guide-encryption.html - I vomit
>> every time it's implied I should put passwords in the Maven settings
>> file]
>
> Totally agreed!

There are a couple of ways around that.

1) Use settings-security.xml  to store the real
settings-security.xml on a removable device.

2) It would be nice if Maven supported a keyserver of some kind (cf.
Pageant for Putty), but it does not. However one can use the
 element to point to a server that returns the passwords.
I wrote a Java app that acts as a simple keyserver; of course that
needs its own password.

If the device is not present, or the server is not running, you get a
warning message when starting Maven builds.
[When using the keyserver I normally give it a dummy password, as that
avoids the time delay when Maven looks for the server; however one
still gets warnings]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Jochen Wiedmann]

On Tue, Apr 5, 2011 at 10:22 AM, Henri Yandell  wrote:

> Very late, but I've been a tad busy in the new-parent department.

You didn't publish a POM yet, did you? ;-)


> What I do care about is releasing often. Which is farcical given how
> few times I've released. I want to release every month. Every week if
> possible. With minimal effort as I don't have the time to waste
> building releases for code that is fine enough.

I wouldn't want to do that without Maven and the release-plugin
anymore. At work, we've got a project where we do exactly that. And a
release includes publication to Nexus, a web site and a lot of other
stuff, everything with relatively generic pom's. Compared to the
almost unmaintainable Ant scripts with their thousands of lines that
we used in the past, it is a lot better.

In the special case of Apache, there are unfortunately some minor
glitches. One is caused by the fact that we europeans are redirected
to the european SVN mirror, rather than the original in the US. There
is a workaround and I tend to forget it all the time. (I also do
Apache releases rarely.) Another problem is the use of https URL's,
although that should be handled in the parent POM nowadays, for both
Maven 2 and 3.


> [Side note; this is insane:
> http://maven.apache.org/guides/mini/guide-encryption.html - I vomit
> every time it's implied I should put passwords in the Maven settings
> file]

Totally agreed!


Jochen

-- 
I Am What I Am And That's All What I Yam (Popeye)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Henri Yandell]

Very late, but I've been a tad busy in the new-parent department.

Generally I agree with Phil's email. I don't really care though - I
recognize that my main pain with Nexus is a) the experience to know
not to trust magical systems & b) not being full of energy to follow
yet another build system change. I'm sure Maven 3.0 will be coming and
I'll have to find the time to look into that.

I've a bunch of JIRA plugins that are basically dead now because
Atlassian moved to OpenSocial and I don't have the time/interest to
read up on OpenSocial. This is the same - major shifts are costly and
I'm now in the 'can't keep up'. My time is worth more to me than the
novelty of the features :) Sucks to be me.

What I do care about is releasing often. Which is farcical given how
few times I've released. I want to release every month. Every week if
possible. With minimal effort as I don't have the time to waste
building releases for code that is fine enough. If that means pressing
some magic button and Nexus takes care of things; fine. I'm loathe to
read the 7 pages of "How to Release updated for Nexus", but I
recognize that a lot of that is my own lacking. That said 97% of it is
boring as it's really How to Release [the Nexus version] and not the
10 line page that its title implies it should be).

[Side note; this is insane:
http://maven.apache.org/guides/mini/guide-encryption.html - I vomit
every time it's implied I should put passwords in the Maven settings
file]

End of opinion :)

Hen

On Tue, Mar 29, 2011 at 7:50 AM, Phil Steitz  wrote:
>  After another nightmare by an RM who has not cut a release in a
> while, I think we need to do something.  The documentation on the
> Commons web pages describes a process that works.  I suggest that we
> standardize on that process, adding some simple automation scripts
> that RMs can choose to use or not to use for the manual steps and
> stop fussing with Nexus or the maven release plugin.  I cut an RC
> last night in 25 minutes (about 15 of which were spent waiting for
> the [pool] tests to complete) and will likely spend about that same
> amount of time deploying the artifacts to dist/ and what remains of
> our simple, file-and-directory-based replication infrastructure to
> get maven artifacts pushed to the maven repos.  I do use a simple
> shell script to manage invoking the maven commands and copying files
> around to reduce the required time from, say an hour, to 25
> minutes.  The script is in svn.
>
> I prefer the "manual" approach for the following reasons:
>
> 1.  I know what it does.  Exactly, every time.  I know that exactly
> the binaries that we vote on get deployed to dist/ and exactly the
> committed tag is used to build everything.  The process includes
> local generation of artifacts that I can inspect and test locally
> and verify sigs.  I know at each step exactly what is being pushed
> where.
>
> 2.  I know that it works.  Every time.  No pom-tweaking,
> plugin-munging or other half-success management required.
>
> 3.  It has no commercial / proprietary dependencies.  The scripts
> are optional and are in any case, ASF-licensed, committed to svn.
>
> I know others have different opinions on this.  It could be we need
> to support both ways of cutting releases.  I would ask, however,
> that those arguing for the "automagical" approach take a hard look
> at how many volunteer hours are being spent trying to get
> maven/nexus to be a release manager and how comparatively little
> time those of us who take the "manual" approach spend getting our
> releases built and deployed.  While I certainly can't claim to
> produce perfect artifacts (much less code :), I will also point out
> that the only major release quality problem that we have had
> recently was the inadvertent release of a [net] version while
> fiddling with the release plugin.  I don't at all buy the argument
> that the manual approach is "error-prone" as it allows more and
> better opportunities for inspection by the RM and community at each
> stage.
>
> Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Jochen Wiedmann]

On Thu, Mar 31, 2011 at 5:46 PM, sebb  wrote:

> If they are left in Nexus staging, AFAIK they end up in Maven Central
> when promoted.

And your point is?


-- 
I Am What I Am And That's All What I Yam (Popeye)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Ralph Goers]

On Mar 31, 2011, at 8:49 AM, sebb wrote:

> On 31 March 2011 12:08, Jochen Wiedmann  wrote:
>> On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz  wrote:
>> 
>>> And then you need to check the hashes and sigs again since you are
>>> now working with downloaded copies of the files that we voted on.
>>> Seems much easier and more correct to me to just scp the files to
>>> p.a.o., let people vote on them and *move* exactly those files to
>>> /dist.
>> 
>> You don't get the point of Nexus and the maven-release-plugin, Phil.
>> The point is that these files (hashes and sigs) are already created,
>> ready to use and, indeed, will be simply moved to /dist, just as you
>> are suggesting.
> 
> Does the release plugin move the files from the staging directory to /dist 
> then?
> 
> Or does it move the RM's copies of the files to /dist?

Although you said you don't like that the Nexus plugin allows manipulating the 
repo, I could see creating a maven project that does nothing but the required 
operations to promote the maven artifacts and move the non-maven artifacts to 
/dist.  Of course, a Java program could also be used that invokes the Nexus 
APIs, etc.

Ralph

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb]

On 31 March 2011 12:08, Jochen Wiedmann  wrote:
> On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz  wrote:
>
>> And then you need to check the hashes and sigs again since you are
>> now working with downloaded copies of the files that we voted on.
>> Seems much easier and more correct to me to just scp the files to
>> p.a.o., let people vote on them and *move* exactly those files to
>> /dist.
>
> You don't get the point of Nexus and the maven-release-plugin, Phil.
> The point is that these files (hashes and sigs) are already created,
> ready to use and, indeed, will be simply moved to /dist, just as you
> are suggesting.

Does the release plugin move the files from the staging directory to /dist then?

Or does it move the RM's copies of the files to /dist?

>
>> Sorry, I don't buy that.  The tars and zips need to "live" in
>> /dist.  The maven artifacts need to make their way to the maven
>> mirrors.  Having a "staging" repo where we can inspect the maven
>> bits before they get pushed out is great (though I think our homes
>> on p.a.o are fine for this).  Why can't we just push files directly
>> there using scp or Ant tasks and then "promote" them to the rsynch
>> repo using a little script including commands like those in step 3
>> of http://commons.apache.org/releases/release.html?
>
> As I said: Your "little script" would simply be duplicating the
> maven-release-plugin. Which is in no way "little".

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[sebb]

On 31 March 2011 12:05, Jochen Wiedmann  wrote:
> On Thu, Mar 31, 2011 at 1:36 AM, sebb  wrote:
>
>> AFAIK, wget alone won't do, as the files also have to be deleted.
>
> Why? There's no problem with leaving them where they are.

If they are left in Nexus staging, AFAIK they end up in Maven Central
when promoted.

>
>> Also, it would be best if that part of the process could be done from
>> the users system, rather than having to login to people.a.o and run
>> commands there.
>>
>> If that could be automated, I would be happy, but would everyone else?
>
> Nothing wrong with that idea, because that area isn't covered by
> either Nexus nor the maven-release-plugin. The work that we spend here
> might even be adopted by other Apache projects. But that wasn't the
> initial point of the discussion, was it?

I thoought the point was to improve the release process.
Since we already use Nexus, I was exploring how the release of dist/
archives could be improved.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Release process WAS [VOTE] Release Apache Commons Codec 1.5-RC1

[Jochen Wiedmann]

On Thu, Mar 31, 2011 at 2:38 AM, Phil Steitz  wrote:

> And then you need to check the hashes and sigs again since you are
> now working with downloaded copies of the files that we voted on.
> Seems much easier and more correct to me to just scp the files to
> p.a.o., let people vote on them and *move* exactly those files to
> /dist.

You don't get the point of Nexus and the maven-release-plugin, Phil.
The point is that these files (hashes and sigs) are already created,
ready to use and, indeed, will be simply moved to /dist, just as you
are suggesting.


> Sorry, I don't buy that.  The tars and zips need to "live" in
> /dist.  The maven artifacts need to make their way to the maven
> mirrors.  Having a "staging" repo where we can inspect the maven
> bits before they get pushed out is great (though I think our homes
> on p.a.o are fine for this).  Why can't we just push files directly
> there using scp or Ant tasks and then "promote" them to the rsynch
> repo using a little script including commands like those in step 3
> of http://commons.apache.org/releases/release.html?

As I said: Your "little script" would simply be duplicating the
maven-release-plugin. Which is in no way "little".





-- 
I Am What I Am And That's All What I Yam (Popeye)

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org