You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Siegfried Goeschl <si...@it20one.at> on 2008/11/21 00:40:39 UTC
[VOTE] Release of fulcrum-yaafi-crypto-1.0.6
Hi folks,
I would like to release fulcrum-yaafi-crypto-1.0.6 as first full-blown
M2 release
+) fulcrum-yaafi-crypto was refactored from fulcrum-yaafi to separate
encryption/decryption from the Avalon container
+) it contains the transparent configuration file decryption support
+) this separation was driven by concerns regarding ECCN export code
(ECCN is sort of viral)
+) I intend to keep the version number in sync with fulcrum-yaafi
Tag:
https://svn.apache.org/repos/asf/turbine/fulcrum/tags/FULCRUM_YAAFI_CRYPTO_1_0_6_RC1
Site:
http://people.apache.org/~sgoeschl/download/fulcrum-yaafi-crypto-1.0.6-RC1/site/
Distributable:
http://people.apache.org/~sgoeschl/download/fulcrum-yaafi-crypto-1.0.6-RC1
+-0/1 as you think fit, thanks!
[ ] +1
[ ] =0
[ ] -1
Vote is open for 96 hours ...
Siegfried Goeschl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: [VOTE] Release of fulcrum-yaafi-crypto-1.0.6
Posted by Scott Eade <se...@backstagetech.com.au>.
Siegfried Goeschl wrote:
> Hi Scott,
>
> I'm sorry for the long delay but I had to meet a project deadline today and your question needs a thoughtful answer ...
>
>
> Some Prerequisites
> =========================================================================
>
> +) we need a quick and painless way to release a fulcrum component
> +) I would like to release a lot of them and I can't spend half a day on a single release
> +) I personally don't have the same quality requirements for releasing a fulcrum component as I would have on commons or maven-plugins
>
I agree on the above three points.
> +) in commons land the discussion is ongoing (or http://wiki.apache.org/commons/CreatingReleases)
>
I'm going to rely on you to keep an eye on developments in the
discussion - so much to read, so little time.
>
> There a many ways to skin the cat
> =========================================================================
>
> 1) follow the guidelines found here (http://maven.apache.org/developers/release/releasing.html)
> 2) make the release from SVN directly also using the release plugin
>
> Ad 1) that stuff is complicated and is probably fragile
>
> Ad 2) this is much quicker but if multiple developers are working on the code it can break. So you should declare a "ceasefire" before running the release process but we have not a lot of SVN activity anyway so this is not an issue.
>
We are certainly not tripping over one and other to release components
(or anything else for that matter).
> Using 2) has two flavors
>
> 2.1) make a complete release using "mvn release:prepare" and "mvn release:perform" - in this case the review needs to be done on an RC tag since the release tag is created only during the release process. This approach I used for releasing the fulcrum-parent.pom
>
So to be clear, does this mean that after the vote a new release is cut
using the final tag which is then deployed? If it is a repeatable
process with only the version changing in the pom then this is probably
acceptable.
> 2.2) run "mvn release:prepare", create the artifacts for reviewing and do "mvn -D connectionUrl release:preform". If the review fails you need to remove the SVN tag which is kind of dirty because that SVN directory should be considered read-only. But again not a big issue
>
>
> Conclusio
> =========================================================================
>
> +) setting up the release process is difficult since it has many implications and subtle problems
> +) I personally lean towards 2.1) or 2.2)
>
I don't think we can afford to be anything other than pragmatic. We
need to follow the rules in terms of reviewing code and releases, but
the process needs to be as quick and painless as possible, so you have
my full support in moving our processes in this direction.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: [VOTE] Release of fulcrum-yaafi-crypto-1.0.6
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Scott,
I'm sorry for the long delay but I had to meet a project deadline today and your question needs a thoughtful answer ...
Some Prerequisites
=========================================================================
+) we need a quick and painless way to release a fulcrum component
+) I would like to release a lot of them and I can't spend half a day on a single release
+) I personally don't have the same quality requirements for releasing a fulcrum component as I would have on commons or maven-plugins
+) in commons land the discussion is ongoing (or http://wiki.apache.org/commons/CreatingReleases)
There a many ways to skin the cat
=========================================================================
1) follow the guidelines found here (http://maven.apache.org/developers/release/releasing.html)
2) make the release from SVN directly also using the release plugin
Ad 1) that stuff is complicated and is probably fragile
Ad 2) this is much quicker but if multiple developers are working on the code it can break. So you should declare a "ceasefire" before running the release process but we have not a lot of SVN activity anyway so this is not an issue.
Using 2) has two flavors
2.1) make a complete release using "mvn release:prepare" and "mvn release:perform" - in this case the review needs to be done on an RC tag since the release tag is created only during the release process. This approach I used for releasing the fulcrum-parent.pom
2.2) run "mvn release:prepare", create the artifacts for reviewing and do "mvn -D connectionUrl release:preform". If the review fails you need to remove the SVN tag which is kind of dirty because that SVN directory should be considered read-only. But again not a big issue
Conclusio
=========================================================================
+) setting up the release process is difficult since it has many implications and subtle problems
+) I personally lean towards 2.1) or 2.2)
Cheers,
Siegfried Goeschl
Scott Eade wrote:
> Hi Siegfried,
>
> Can you please clarify if this to release 1.0.6-RC1 or 1.0.6 final?
> From the subject I would infer the latter, but the links below suggest
> the former. If it is 1.0.6 final it would seem that the site and the
> artifacts are going to be regenerated, so arguable we would be
> checking the wrong things here.
>
> Does your new Fulcrum M2 Migration wiki page cover deployment to the
> staging site (in this case your personal apache webspace)? That would
> be helpful.
>
> Great to see some progress on this. I am certainly not trying to
> block things, just to understand the new process that is likely to be
> used extensively in the future.
>
> Scott
>
> Siegfried Goeschl wrote:
>> Hi folks,
>>
>> I would like to release fulcrum-yaafi-crypto-1.0.6 as first full-blown
>> M2 release
>>
>> +) fulcrum-yaafi-crypto was refactored from fulcrum-yaafi to separate
>> encryption/decryption from the Avalon container
>> +) it contains the transparent configuration file decryption support
>> +) this separation was driven by concerns regarding ECCN export code
>> (ECCN is sort of viral)
>> +) I intend to keep the version number in sync with fulcrum-yaafi
>>
>> Tag:
>> https://svn.apache.org/repos/asf/turbine/fulcrum/tags/FULCRUM_YAAFI_CRYPTO_1_0_6_RC1
>>
>> Site:
>> http://people.apache.org/~sgoeschl/download/fulcrum-yaafi-crypto-1.0.6-RC1/site/
>>
>> Distributable:
>> http://people.apache.org/~sgoeschl/download/fulcrum-yaafi-crypto-1.0.6-RC1
>>
>>
>> +-0/1 as you think fit, thanks!
>>
>> [ ] +1
>> [ ] =0
>> [ ] -1
>>
>> Vote is open for 96 hours ...
>>
>>
>> Siegfried Goeschl
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
> For additional commands, e-mail: dev-help@turbine.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org
Re: [VOTE] Release of fulcrum-yaafi-crypto-1.0.6
Posted by Scott Eade <se...@backstagetech.com.au>.
Hi Siegfried,
Can you please clarify if this to release 1.0.6-RC1 or 1.0.6 final?
From the subject I would infer the latter, but the links below suggest
the former. If it is 1.0.6 final it would seem that the site and the
artifacts are going to be regenerated, so arguable we would be checking
the wrong things here.
Does your new Fulcrum M2 Migration wiki page cover deployment to the
staging site (in this case your personal apache webspace)? That would
be helpful.
Great to see some progress on this. I am certainly not trying to block
things, just to understand the new process that is likely to be used
extensively in the future.
Scott
Siegfried Goeschl wrote:
> Hi folks,
>
> I would like to release fulcrum-yaafi-crypto-1.0.6 as first full-blown
> M2 release
>
> +) fulcrum-yaafi-crypto was refactored from fulcrum-yaafi to separate
> encryption/decryption from the Avalon container
> +) it contains the transparent configuration file decryption support
> +) this separation was driven by concerns regarding ECCN export code
> (ECCN is sort of viral)
> +) I intend to keep the version number in sync with fulcrum-yaafi
>
> Tag:
> https://svn.apache.org/repos/asf/turbine/fulcrum/tags/FULCRUM_YAAFI_CRYPTO_1_0_6_RC1
> Site:
> http://people.apache.org/~sgoeschl/download/fulcrum-yaafi-crypto-1.0.6-RC1/site/
> Distributable:
> http://people.apache.org/~sgoeschl/download/fulcrum-yaafi-crypto-1.0.6-RC1
>
> +-0/1 as you think fit, thanks!
>
> [ ] +1
> [ ] =0
> [ ] -1
>
> Vote is open for 96 hours ...
>
>
> Siegfried Goeschl
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org