You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2008/08/05 17:11:45 UTC
Next SCA release
Now that 1.3 is just out I'd like to do another release! Its been over a
month since the 1.3 branch was taken from trunk and I've been doing a lot of
work on the JMS binding since then so would like to get that code released.
The 1.2.1 release showed its not too much work to do a point release so I
wondered about doing a point release from the 1.3 branch with just the new
changes for the JMS binding and what ever other small JIRAs may be ready.
Comments?
...ant
Re: Next SCA release
Posted by Simon Nash <na...@apache.org>.
ant elder wrote:
>
>
> On Fri, Aug 8, 2008 at 11:10 AM, ant elder <ant.elder@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Fri, Aug 8, 2008 at 9:27 AM, Simon Laws
> <simonslaws@googlemail.com <ma...@googlemail.com>> wrote:
>
> <snip>
>
>
>
> Re. JMS. I'm a little nervous about putting completely new
> function out in 1.3.1. <http://1.3.1.> JMS changes that fix
> deficiencies from 1.3 would be candidates though.
>
>
>
> What is it that makes you nervous about adding the JMS changes?
> There are no "rules" about what should go into a release named 1.x
> as opposed to 1.x.x so i think its fine to add new function in a
> 1.x.x style release. If the concern is that it may delay getting
> some critical fixes released then maybe we just need to coordinate
> 1.3.1 and 1.3.2 releases?
>
> Doing releases based on the previous release tag is relatively easy
> as demonstrated by the 1.2.1 release. It takes minimal work to do
> and to review, it makes it easy to document the changes, its an easy
> way to get new function released, and it can be done by individuals
> instead of requiring lots of community help. As i just suggested on
> the "1.3 Washup, release process improvement" this seems like and
> easy way to RERO given the size of Tuscany these days.
>
> ...ant
>
>
> I'll start making the 1.3.1 branch today and merge in and fixes from
> JIRAs in Java-SCA-1.3.1. The main one outstanding is TUSCANY-2539 if
> anyone has some time. I'll leave the JMS changes for the time being
> waiting a little longer to see if there are any reasons why it should
> not go into 1.3.x.
>
I have completed the fix for TUSCANY-2531 now. This needs to go into
1.3.1. The fix passes a full build and I'll check it in later today.
Simon
Re: Next SCA release
Posted by Simon Nash <na...@apache.org>.
Simon Laws wrote:
>
>
> On Mon, Aug 11, 2008 at 7:33 AM, ant elder <ant.elder@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Fri, Aug 8, 2008 at 11:10 AM, ant elder <ant.elder@gmail.com
> <ma...@gmail.com>> wrote:
>
>
>
> On Fri, Aug 8, 2008 at 9:27 AM, Simon Laws
> <simonslaws@googlemail.com <ma...@googlemail.com>>
> wrote:
>
> <snip>
>
>
>
> Re. JMS. I'm a little nervous about putting completely new
> function out in 1.3.1. <http://1.3.1.> JMS changes that fix
> deficiencies from 1.3 would be candidates though.
>
>
>
> What is it that makes you nervous about adding the JMS changes?
> There are no "rules" about what should go into a release named
> 1.x as opposed to 1.x.x so i think its fine to add new function
> in a 1.x.x style release. If the concern is that it may delay
> getting some critical fixes released then maybe we just need to
> coordinate 1.3.1 and 1.3.2 releases?
>
> Doing releases based on the previous release tag is relatively
> easy as demonstrated by the 1.2.1 release. It takes minimal work
> to do and to review, it makes it easy to document the changes,
> its an easy way to get new function released, and it can be done
> by individuals instead of requiring lots of community help. As i
> just suggested on the "1.3 Washup, release process improvement"
> this seems like and easy way to RERO given the size of Tuscany
> these days.
>
> ...ant
>
>
> I'll start making the 1.3.1 branch today and merge in and fixes from
> JIRAs in Java-SCA-1.3.1. The main one outstanding is TUSCANY-2539 if
> anyone has some time. I'll leave the JMS changes for the time being
> waiting a little longer to see if there are any reasons why it
> should not go into 1.3.x.
>
> ...ant
>
>
> It wasn't really a philosophical objection to putting new function in
> the release. More a comment on how much work is required to test and
> verify a release with new function in it.
>
I think we should be very careful about this. If the new function is
very isolated and we are very confident that it won't cause problems,
it may make sense. Remember the bad experience with 1.0.1!
There's a good case for releasing important fixes that are causing serious
user problems by means of 1.x.x releases of very limited-scope. For new
function, I think it's generally better to do this as 1.x. If and when
we do a release that breaks backwards compatibility on APIs or SPIs,
I think that would justify moving to 2.x.
Simon
Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Aug 11, 2008 at 7:33 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Fri, Aug 8, 2008 at 11:10 AM, ant elder <an...@gmail.com> wrote:
>
>>
>>
>> On Fri, Aug 8, 2008 at 9:27 AM, Simon Laws <si...@googlemail.com>wrote:
>>
>> <snip>
>>
>>
>>> Re. JMS. I'm a little nervous about putting completely new function out
>>> in 1.3.1. JMS changes that fix deficiencies from 1.3 would be candidates
>>> though.
>>>
>>>
>>>
>> What is it that makes you nervous about adding the JMS changes? There are
>> no "rules" about what should go into a release named 1.x as opposed to 1.x.x
>> so i think its fine to add new function in a 1.x.x style release. If the
>> concern is that it may delay getting some critical fixes released then maybe
>> we just need to coordinate 1.3.1 and 1.3.2 releases?
>>
>> Doing releases based on the previous release tag is relatively easy as
>> demonstrated by the 1.2.1 release. It takes minimal work to do and to
>> review, it makes it easy to document the changes, its an easy way to get new
>> function released, and it can be done by individuals instead of requiring
>> lots of community help. As i just suggested on the "1.3 Washup, release
>> process improvement" this seems like and easy way to RERO given the size of
>> Tuscany these days.
>>
>> ...ant
>>
>>
> I'll start making the 1.3.1 branch today and merge in and fixes from JIRAs
> in Java-SCA-1.3.1. The main one outstanding is TUSCANY-2539 if anyone has
> some time. I'll leave the JMS changes for the time being waiting a little
> longer to see if there are any reasons why it should not go into 1.3.x.
>
> ...ant
>
>
It wasn't really a philosophical objection to putting new function in the
release. More a comment on how much work is required to test and verify a
release with new function in it.
Simon
Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Fri, Aug 8, 2008 at 11:10 AM, ant elder <an...@gmail.com> wrote:
>
>
> On Fri, Aug 8, 2008 at 9:27 AM, Simon Laws <si...@googlemail.com>wrote:
>
> <snip>
>
>
>> Re. JMS. I'm a little nervous about putting completely new function out in
>> 1.3.1. JMS changes that fix deficiencies from 1.3 would be candidates
>> though.
>>
>>
>>
> What is it that makes you nervous about adding the JMS changes? There are
> no "rules" about what should go into a release named 1.x as opposed to 1.x.x
> so i think its fine to add new function in a 1.x.x style release. If the
> concern is that it may delay getting some critical fixes released then maybe
> we just need to coordinate 1.3.1 and 1.3.2 releases?
>
> Doing releases based on the previous release tag is relatively easy as
> demonstrated by the 1.2.1 release. It takes minimal work to do and to
> review, it makes it easy to document the changes, its an easy way to get new
> function released, and it can be done by individuals instead of requiring
> lots of community help. As i just suggested on the "1.3 Washup, release
> process improvement" this seems like and easy way to RERO given the size of
> Tuscany these days.
>
> ...ant
>
>
I'll start making the 1.3.1 branch today and merge in and fixes from JIRAs
in Java-SCA-1.3.1. The main one outstanding is TUSCANY-2539 if anyone has
some time. I'll leave the JMS changes for the time being waiting a little
longer to see if there are any reasons why it should not go into 1.3.x.
...ant
Re: Next SCA release
Posted by ant elder <an...@gmail.com>.
On Fri, Aug 8, 2008 at 9:27 AM, Simon Laws <si...@googlemail.com>wrote:
<snip>
> Re. JMS. I'm a little nervous about putting completely new function out in
> 1.3.1. JMS changes that fix deficiencies from 1.3 would be candidates
> though.
>
>
>
What is it that makes you nervous about adding the JMS changes? There are
no "rules" about what should go into a release named 1.x as opposed to 1.x.x
so i think its fine to add new function in a 1.x.x style release. If the
concern is that it may delay getting some critical fixes released then maybe
we just need to coordinate 1.3.1 and 1.3.2 releases?
Doing releases based on the previous release tag is relatively easy as
demonstrated by the 1.2.1 release. It takes minimal work to do and to
review, it makes it easy to document the changes, its an easy way to get new
function released, and it can be done by individuals instead of requiring
lots of community help. As i just suggested on the "1.3 Washup, release
process improvement" this seems like and easy way to RERO given the size of
Tuscany these days.
...ant
Re: Next SCA release
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Aug 7, 2008 at 10:35 PM, Dave Sowerby <da...@gmail.com>wrote:
> Hey Ant,
>
> I definitely agree - the 1.2.1 release was very worthwhile in terms of
> being able to quickly turnaround a new release with critical bug fixes
> included, so now that 1.3 is out and I'd like a few more fixes
> included soon then it definitely gets my +1 :)
>
> This is my list of ideal inclusions for 1.3.1, along with a brief
> comment on the priority for me as well as a comment on it's situation:
>
> o TUSCANY-2531: Critical
>
> o TUSCANY-2535: High, fix already present and tested
>
> o TUSCANY-2539: High, no current fix
>
> o TUSCANY-2534: High, though with workaround
>
> o TUSCANY-2514: Nice to have, though confusing currently
>
> Does any one have any thoughts on the applicability/ability of
> inclusion for these issues' fixes for 1.3.1?
>
> Cheers,
>
> Dave.
>
> --
> Dave Sowerby MEng MBCS
>
>
> On Tue, Aug 5, 2008 at 4:11 PM, ant elder <an...@gmail.com> wrote:
> > Now that 1.3 is just out I'd like to do another release! Its been over a
> > month since the 1.3 branch was taken from trunk and I've been doing a lot
> of
> > work on the JMS binding since then so would like to get that code
> released.
> > The 1.2.1 release showed its not too much work to do a point release so I
> > wondered about doing a point release from the 1.3 branch with just the
> new
> > changes for the JMS binding and what ever other small JIRAs may be ready.
> >
> > Comments?
> >
> > ...ant
> >
> >
> >
> >
>
Hi
Re. JMS. I'm a little nervous about putting completely new function out in
1.3.1. JMS changes that fix deficiencies from 1.3 would be candidates
though.
As we took so long to get 1.3 out we should probably start 1.4 straight away
for new function. We need to vastly improve our release process though. So
some thoughts...
- Start 1.3.1 straight away to include immediate issues outstanding for 1.3
- Start 1.4 to release new function from trunk
- have a washup of 1.3 for areas we need to improve re. our release process
- either use 1.4 as an input to the process improvement or as a guinea-pig
for process improvements (depends how quickly we want to do 1.4).
Re. Dave's JIRA. It looks like we should definitely look at the top 3 (one
of them is already done). I'd also like to do TUSCANY-2534 as that's a bit
of a mystery. I'd associate them all with the 1.3.1 tag in JIRA and this
will help us define 1.3.1. Depending on how may other bugs we get there we
may need to set a cut off but let's see.
Regards
Simon
Re: Next SCA release
Posted by Dave Sowerby <da...@gmail.com>.
Hey Ant,
I definitely agree - the 1.2.1 release was very worthwhile in terms of
being able to quickly turnaround a new release with critical bug fixes
included, so now that 1.3 is out and I'd like a few more fixes
included soon then it definitely gets my +1 :)
This is my list of ideal inclusions for 1.3.1, along with a brief
comment on the priority for me as well as a comment on it's situation:
o TUSCANY-2531: Critical
o TUSCANY-2535: High, fix already present and tested
o TUSCANY-2539: High, no current fix
o TUSCANY-2534: High, though with workaround
o TUSCANY-2514: Nice to have, though confusing currently
Does any one have any thoughts on the applicability/ability of
inclusion for these issues' fixes for 1.3.1?
Cheers,
Dave.
--
Dave Sowerby MEng MBCS
On Tue, Aug 5, 2008 at 4:11 PM, ant elder <an...@gmail.com> wrote:
> Now that 1.3 is just out I'd like to do another release! Its been over a
> month since the 1.3 branch was taken from trunk and I've been doing a lot of
> work on the JMS binding since then so would like to get that code released.
> The 1.2.1 release showed its not too much work to do a point release so I
> wondered about doing a point release from the 1.3 branch with just the new
> changes for the JMS binding and what ever other small JIRAs may be ready.
>
> Comments?
>
> ...ant
>
>
>
>