Ah yes, you're right Ben. I was confused between milestones and release stages.
Subtract another mark from my score.
Michael
On 5 May 2011 13:32, Ben Caradoc-Davies wrote:
> To be clearer: in my view, if you want to make this change, and the
> community agrees, then it should be made on trunk b
To be clearer: in my view, if you want to make this change, and the
community agrees, then it should be made on trunk before we start the
8.0 release train (and branch 8.x). Note that milestones are persistent
snapshots of trunk. They are not part of the release train. Is this the
cause of your
On 5 May 2011 13:24, Ben Caradoc-Davies wrote:
> Change that breaks compatibility is what trunk is for. :-)
>
But aren't we in a sort of transitional period ? If trunk is feeding
into 8-Mn at the moment I thought it might be naughty to commit
changes that should be in 9.x under the new regime..
Change that breaks compatibility is what trunk is for. :-)
On 05/05/11 11:19, Michael Bedward wrote:
> My item #3 (bringing swing branch code over) will most probably break
> backwards compatibility. I haven't looked at that code for a while but
> I doubt I can do it with only additions to the cu
Ah, Mr Nice (50%) and Mr Nasty (33%)...
My item #3 (bringing swing branch code over) will most probably break
backwards compatibility. I haven't looked at that code for a while but
I doubt I can do it with only additions to the current API. So that
will mean it couldn't be in 8.x - yes ?
Michael
1/3 [your (1) was right], as I understand it.
8.x is trunk; it has not yet been forked. We are free to make whatever
changes we like on trunk, including breaking backwards compatibility,
upgrading to Java 6, or rewriting it all in Scala, subject to community
process.
2.7.x is stable, so must n
Afternoon Michael:
Comments inline...
> I'd like to check my understanding of the new versioning scheme for my
> current housekeeping on the swing module. Although swing is still an
> unsupported module it has a lot of users, so I'd like to treat any
> changes as per the rules for supported module
Hello all,
I'd like to check my understanding of the new versioning scheme for my
current housekeeping on the swing module. Although swing is still an
unsupported module it has a lot of users, so I'd like to treat any
changes as per the rules for supported modules.
The following is my understandi
