Re: Next SCA release

[Simon Nash]

Simon Laws wrote:

On Mon, Aug 11, 2008 at 7:33 AM, ant elder <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    On Fri, Aug 8, 2008 at 11:10 AM, ant elder <[EMAIL PROTECTED]
    <mailto:[EMAIL PROTECTED]>> wrote:



        On Fri, Aug 8, 2008 at 9:27 AM, Simon Laws
        <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
        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