On 9/17/07, Paul McMahan <[EMAIL PROTECTED]> wrote: > > I agree that 2.0.2 should be limited to bug fixes but I think new > features are OK as long as they are very low risk and don't cause any > backwards compatibility problems. I think when users pick up a x.y.z > +1 release they want and expect minimal risk and disruption. Right > now GERONIMO-2925 is classified in JIRA as Type: Bug, Priority: > Critical. So if we're OK with that classification then sound like > it's a good candidate for 2.0.2. Otherwise let's update the JIRA. > > As for the directory per web-app feature, the JIRA (GERONIMO-2964) > contains a lot of discussion about schema changes and version > compatibility, which tends to raise an eyebrow about its inclusion in > 2.0.2. But the schema changes may be minor and backwards compatible > (?), and the reported problems with plugin compatibility might be a > false alarm because the plugins in 2.0.1 may not have been working > correctly in the first place? I am still a little confused about > that. Once the final solution for that item has been committed to > trunk I think it would be a good idea to summarize how it might > affect 2.0.1 users (especially w.r.t. backwards compatibility) so > that the community and release manager can help weigh in on whether > or not it should be merged to the 2.0 branch.
I don't think the schema changes will come in the way of backward compatibility of plugins. I have proposed a patch for branches\2.0 without changing constructors or methods so that it won't come in the way of compatibility. But in the process I noticed that jsp-examples and servlet-examples cars from 2.0.1 won't run on G 2.0.1 due to a default-subject in the plans and won't install on 2.0.2-SNAPSHOT due to a change to Holder class. There may be other plugins that may unearth other changes that have already broken compatibility. If someone is going to take up finding and fixing all those compatibility breaking changes, it may be worth considering the "no constructor change" patch for trunk too. Also, it may be a good idea to add some tests for the compatibility we want to preserve across versions!! Joe, you mentioned TCK and our ability to make 2.0.2 available by > 9/21. I have a question for the team about that. I would like to > bump Geronimo's version of MyFaces from 1.2.0 to 1.2.1 since that new > release contains several bug fixes, some of them actually found and > reported by Geronimo users. But doing that could affect Geronimo's > TCK results and affect the 9/21 delivery date. I would imagine that > the same is true for other dependencies. Are we OK with picking up > maintenance releases of Geronimo dependencies in 2.0.2 even if we > think TCK issues could slow us down? Or should we keep 2.0.2 > focused on "localized" changes and only bump the dependency versions > in Geronimo 2.1 so we have more time to deal any resulting TCK issues? > > Best wishes, > Paul > > > On Sep 17, 2007, at 9:25 AM, Joe Bohn wrote: > > > I agree 2.0.2 should be primarily bug fixes but I don't think it > > must be limited to only bug fixes. If there are small changes that > > address customer concerns on security (such as GERONIMO-2925) or > > usability then I think those can be considered for inclusion. Key > > is to keep the date Kevan proposed (Friday, 9/21) and resolve any > > TCK issues. > > > > Joe > > > > > > David Jencks wrote: > >> I'm starting to wonder what the goal for 2.0.2 is. I kinda > >> thought that a x.y.z where z > 0 was a bugfix-only release of > >> x.y.z-1 but I think some new features are going into 2.0.2... > >> IIUC Vamsi is applying an enhancement to allow specifying work > >> directory per-web-app and donald is encouraging me to apply my > >> proposal to GERONIMO-2925 to the branch. Though small these are > >> definitely new features. > >> Personally I would prefer to minimize such feature creep and have > >> more focus on getting 2.1 out in a less than geological time > >> frame, in particular before apachecon atlanta. > >> What do others think? > >> thanks > >> david jencks > >
