ant elder wrote:
On 9/20/07, Simon Laws <[EMAIL PROTECTED]> wrote:
---------- Forwarded message ----------
From: Venkata Krishnan <[EMAIL PROTECTED]>
Date: Sep 20, 2007 8:16 AM
Subject: Re: Change freeze on 1.0 branch
To: [email protected], [EMAIL PROTECTED]
+1... makes lot of sense to me
- Venkat
On 9/20/07, ant elder <[EMAIL PROTECTED]> wrote:
Just a reminder there is still a change freeze on the 1.0 branch.
Its still possible we may need to respin for some reason, but how about
also
planning on doing some 1.0.x releases after 1.0 is out? If we keep
changes
in the branch to an absolute minimum it should be easy to do
1.0.xreleases
after all the 1.0 reviewing so we can just show a small diff of 1.0 -
1.0.xand review/voting should be painless so we could do
1.0.x release every 1 or 2 weeks if necessary. With that in mind how
about
we switch to Review-Then-Commit mode on the branch - so all changes get
attached as diff to a JIRA and can only be applied to the branch with 3
+1s
on the ML?
...ant
On 9/19/07, ant elder <[EMAIL PROTECTED]> wrote:
Looks like 1.0 is getting pretty close now so can we have a change
freeze
on the 1.0 branch to avoid any last minute regressions please - no
updates
to it without asking first.
We need an RC4 to fix the missing xquery sample and the ws.zones repo,
but
i'd hope RC4 can be the final one. Please continue reviewing RC3 and
raising
jira's for any issues you find (and finding fixes for the issues!),
and
i'll
cut an RC4 late today. Lets try to keep the RC4 vote thread clean - so
just
+1/-1 and anything else in a jira. If you do find a serious issue be
great
if you could say something like "+1 as long as jira xxx is resolved".
Thanks!
...ant
Hi
It feels like we have been getting better at using JIRA in the run up to
0.99 and 1.0 release in terms of the consistency with which we raise bug
reports and assign them to releases. Based on Ant's branch freeze
suggestion
how about we now
1/ create the following versions in JIRA
JAVA-SCA-1.1 - as the trunk target
JAVA-SCA-1.0.1 - as the 1.0 branch target in case we need it
2/ Review the JIRA components to make them match the modules we currently
have. Several options here, e.g.
a/ add a component for any module we have in svn that is not represented
b/ stick with the shorter list, as we have now, making sure we have one
for each extension and general ones for Itests, samples, demos ,
distribution etc.
3/ Continue the theme of creating JIRAs for the bug/enhancements we see
and
assigning them to the release where we want them to be fixed.
B.t.w I'm happy to do admin tasks as appropriate.
Simon
All those sound good to me. For 2/ i'd go for b/ - the shorter list, and do
some review/cleanup of the current list of the components we have or at
least come up with some clear reasons why we need each separate component.
...ant
+1 for a cleaned up version of the shorter list. And +1 for Simon's
other proposals.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
