I think it makes sense to get the 2.0.1 release out and then target 2.1. If 2.0.1 escapes into the wild with bugs that need fixing, we can push out a 2.0.2 release to do so, but otherwise think 2.1 is fine for the next release number. (Unless there is some conflicting Pivot/ASF numbering policy that I am not aware of)
Therefore I would be happy to move any outstanding 2.0.x JIRA tickets to 2.1 when 2.0.1 is released. On 13 August 2011 07:32, Sandro Martini <sandro.mart...@gmail.com> wrote: > Hi all, > in last weeks we exchanged many mails on the need to release soon the (much > awaited) 2.0.1 and now thanks to the work of all us, we are near to release > it, finally !! > > The point I'd like to discuss with others is this: > in the 2.0.x line we have many tickets, probably some could be moved to 2.1 > to not delay too much the start of developments on 2.1 , right ? > > So we could start by fixing remaining (real and backward compatible) issues > now and see in some weeks (after the release of 2.0.1) if needed a 2.0.2 > from sources in trunk, or if use it for 2.1 (copying 2.0.1 in a 2.0.x > maintenance branch, but only after some weeks) ? > All this because issues for 2.0.x are even for 2.1, but double merge are > time consuming, and we have few time (at least me). > > I hope to be clear in my description :-) ... > > Comments are highly appreciated, by all, even not only Pivot developers ... > > Bye >
