27 May
2012
27 May
'12
5:43 a.m.
On 05/23/2012 06:51 AM, Thomas Mortagne wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Tue, May 22, 2012 at 5:11 PM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> wrote:
Not quite, since maven-release.sh should just handle the maven release.
But we could add a pre-release.sh script that handles Jira.
On 05/22/2012 04:52 AM, Vincent Massol wrote:
We should probably move the jira update from push-release.sh to
maven-release.sh and executed right after we finished releasing a
project. It was already a big fuzzy even before since you could have
commons actually released since a long time before you actually
release it on jira (not time to finish the full release, etc...).
On May 22, 2012, at 10:55 AM, Caleb James DeLisle wrote:
Sounds good, to prevent issues having their fix-for version set as the released version,
it makes sense to release on jira right away but post-date the release so that dates line
up.
Anyway this is something we can leave open to experimentation until the right decision
makes itself obvious. Hi,
I'd like to add staging to our official release process.
For milestone releases, I propose the staging cycle be for "0 time" (this may
be revisited later).
+1
For RC or finals, we place the release in staging
and immediately call a VOTE to publish the release, this gives our testing team
(everybody!) 72 hours to raise a potential issue.
+1 with the proviso that we need to take that into account when we publish release dates.
When we say that 4.1RC1 will be released on 11th of June, I guess it means we need to
release RC1 on 11th - 72 hours then?
Caleb
>
>> Why:
>>
>> #1. After some chat on IRC I decided that it is advantageous to move toward a
faster release cycle and begin moving away from milestone releases in favor of staging.
This will set the stage for the release method we will need.
>>
>> #2. Staging is easy, I've modified the release script to include staging and
with the script, it is a simple matter of about 5 clicks on nexus to "login",
"close repository", "release repository".
>>
>> #3. Staging is safe, the RM need not worry about fat fingers breaking the
release, all it costs is time.
>>
>> #4. The release process should be as close to the same as possible for milestone
and RC/final releases. This simplifies scripting of the process, decreases the amount the
RM must remember and makes every milestone release a rehearsal.
>>
>> #5. Everybody else is doing it (is that even a reason?!)
>>
>>
>> Mandatory?
>> I would rather impress the RM with how easy and helpful staging can be than bind
him with rules.
>> If I had followed the existing process to the letter, I would not have had any
experience with staging to begin with.
>> In the interest of continuous improvement I would like to make this a strong
recommendation, not a strict rule.
>>
>>
>> Here's my +1
>
> +1
+1