+1. If there are any issues when people start using 1.0, this is a
good way to take care of them. Would the intention be to limit changes
in the branch to fixes for significant functional problems, or to also
apply patches for the various minor non-functional glitches that have
been found in the reviews of RC3a?
Simon
Venkata Krishnan wrote:
+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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
