On 9/26/07, ant elder <[EMAIL PROTECTED]> wrote: > > On 9/25/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > On 9/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > > > [snip] > > > Simon Laws wrote: > > > > Hi > > > > > > > > It feels like we have been getting better at using JIRA in the run > up > > to > > > > 0.99 and 1.0 release in terms of the consistency with which we raise > > bug > > > > reports and assign them to releases. Based on Ant's branch freeze > > > suggestion > > > > how about we now > > > > > > > > 1/ create the following versions in JIRA > > > > JAVA-SCA-1.1 - as the trunk target > > > > JAVA-SCA-1.0.1 - as the 1.0 branch target in case we need it > > > > > > > > > > Dare I ask :) Java SCA 1.0.1 has 12 unresolved issues? Is anybody > > > working on fixing these 12 issues for a 1.0.1 release different from > 1.1 > > ? > > > > > > When can I download 1.0.1? > > > > > > > 2/ Review the JIRA components to make them match the modules we > > > currently > > > > have. Several options here, e.g. > > > > a/ add a component for any module we have in svn that is not > > > represented > > > > b/ stick with the shorter list, as we have now, making sure we > have > > > one > > > > for each extension and general ones for Itests, samples, demos , > > > > distribution etc. > > > > > > > > > > +1 for b, stick to the list we have now, until components disappear or > > > new components emerge and have issues that need to be tracked. > > > > > > > 3/ Continue the theme of creating JIRAs for the bug/enhancements we > > see > > > and > > > > assigning them to the release where we want them to be fixed. > > > > > > > > > > +1 therefore my question above about 1.0.1 :) > > > > B.t.w I'm happy to do admin tasks as appropriate. > > > > > > > > Simon > > > > > > > > > > > > > > > > > -- > > > Jean-Sebastien > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > I think that we, as a community, have to decide what sort of change > would > > necessitate a 1.0.1 release. Looking at the JIRAs there now these can > all > > be > > addressed in 1.1 in my opinion. 1.0.1 would just be for emergencies > when > > people can't take the latest code from trunk for some reason. I will > > reassign them unless anyone shouts. > > > > Simon > > > > "just for emergencies" seems too strong to me, I'll wait a bit to see what > problems get discovered but I'm quite keen on some 1.0.x releases and > think > any common problem that users see with 1.0 could be a candidate. Take > TUSCANY-1795 as an example, if this is really what happens when anyone > tries > the sample then thats not a very good user experience so if its an easy > fix > why not fix it? I think the important thing is to try to keep the changes > in > each 1.0.x release small so its really easy to review and get the votes > through with minimum effort. > > ...ant > Ok, point taken. Emergency was maybe a little strong. The question is how we decide that a 1.0.X release is required. There are no hard and fast rules and no release plan (there has been no release discussion for 1.1 on the list yet either but that is a different discussion). At some point someone will stick their hand up and suggest a 1.0.1 release is required. I was suggesting the trigger for this is a problem that seriously detracts from the usability of 1.0 (a common problem that users see). I.e. we need to set the expectation that just because JIRAs get flagged against 1.0.1 doesn't mean that's where they will get fixed.
Simon
