I also think we should get rid of the 1.1.3 version (change it back to nightly.) This is going to cause a lot of confusion.
We need to have a group dicussion on how we might change JIRA to give better information. Perhaps a field for the "scheduled" version which is independent of the version fixed field ... For now I say change 1.1.3 to nightly and create a 1.1.2 branch in order to minimize confusion. Someone has already asked me offlist which version to report their bug against (they were using the nightly build but now there is 1.1.2 and 1.1.3). sean On 11/21/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > Well I disagree slightly with how this is being handled. I think we > should have created a 1.1.2 branch before getting rid of the nightly > version. And we probably should have taken an informal poll before > doing that. > > I agree that we should have a roadmap before 1.1.2. I agree with > Manfred that we should release tomahawk along with the implementation. > That should be the policy until we have a compelling reason to do > otherwise. If anything there are more useful fixes in tomahawk than > the implementation. > > In the meantime, without a nightly version label in JIRA and without a > 1.1.2 branch, basically every fix that goes into SVN will be part of > the 1.1.2 release. On the other hand, we don't want to be on the > branch for too long either because we will have to merge down and > people using the nightly won't be able to access the last minute > branch changes until that is done. > > At this point, the 1.1.2 JIRA changes have already been made so I > guess we leave them alone and not add a nightly label until we make > the branch. I suggest we branch soon but not until we all agree that > its time for a new release. > > sean > > On 11/21/05, Abrams, Howard A <[EMAIL PROTECTED]> wrote: > > I've done a quick and dirty pass through the open issues, and made the > > following changes: > > > > * Renamed 'Nightly' to '1.1.2' > > * Added a few seemingly very important issues to 1.1.2 > > * Left any open issues already marked for 1.1.2/nightly as-is, > > regardless of my opinion of them (in theory they should be removed > > because non api/impl issues shouldn't hold up a release, right?) > > * Created a new 1.1.3 version > > * Added remaining issues that looked reasonably important to 1.1.3. > > > > I think the next step is for the community to take a look and: > > * Nominate any issues that should be added to 1.1.2 or 1.1.3 > > * Nominate any issues that should be removed from 1.1.2 or 1.1.3 > > > > Then I think we should vote on the 1.1.2 list, and if/when approved, > > move forward with fixing the remaining issues and preparing for a > > release. > > > > Thoughts? Suggestions? > > > > > -----Original Message----- > > > From: Manfred Geiler [mailto:[EMAIL PROTECTED] > > > Sent: Monday, November 21, 2005 2:26 AM > > > To: MyFaces Development > > > Subject: Re: Plan for 1.1.2? > > > > > > Howard, > > > You are now member of "myfaces-developers" group on Jira. Can you > > > please check if this gives you enough rights? > > > Thanks, > > > Manfred > > > > > > 2005/11/21, Abrams, Howard A <[EMAIL PROTECTED]>: > > > > If you're certain that issues on the custom/extended components have > > no > > > > chance of holding up a release (other than taking resources away > > from > > > > fixing issue in the api/impl), then you're right, there isn't a > > need. > > > > However, I think that without a clear plan the issue is confused. > > > > > > > > I think we can use the 'road map' feature of JIRA to pick issues for > > > > each upcoming minor release. I'll volunteer to take a stab at > > creating a > > > > 'road map' for 1.1.2, (if someone can give me any access required). > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Manfred Geiler [mailto:[EMAIL PROTECTED] > > > > > Sent: Monday, November 21, 2005 1:05 AM > > > > > To: MyFaces Development > > > > > Subject: Re: Plan for 1.1.2? > > > > > > > > > > Well, there is nothing to argue against quicker release cycles. > > EXCEPT > > > > > the fact that a new release (not a build!) does not emerge alone, > > ie. > > > > > cannot be fully automated. There are things like release candidate > > > > > voting, testing (!), release notes, homepage updates, > > announcements. > > > > > Which takes time. > > > > > Sean and Bill have spent much much time in releasing so far > > (thanks!) > > > > > and many have helped to make it as easy as possible. But of > > course: > > > > > Any additional help is welcome! > > > > > The more volunteer helpers and testers we have, the faster we can > > have > > > > > our cycles. > > > > > > > > > > As Howard did mention, a release plan would be good. Any volunteer > > who > > > > > is willing to look over the open Jira issues and classify them? > > > > > Any thoughts about future milestones? > > > > > > > > > > -0.5 from my side for releasing the API/impl separately: > > > > > There is no need IMHO. API/Impl are the most important parts. So, > > if > > > > > there really is a showstopper, this alone would legitimate a new > > > > > release. Regardless of small bugs in one of the addons or sub > > > > > projects. > > > > > Thoughts? > > > > > > > > > > Thanks, > > > > > Manfred > > > > > > > > > > > > > > > > > > > > > > > > > 2005/11/20, Travis Reeder <[EMAIL PROTECTED]>: > > > > > > +1 for the quicker release cycle. > > > > > > > > > > > > Travis > > > > > > > > > > > > On 11/20/05, James Mitchell <[EMAIL PROTECTED]> wrote: > > > > > > > Not sure about the release plan, but +1 for a quicker release > > > > cycle. > > > > > > > Let's not get caught up in the same slow cycle that has > > affected > > > > > > > Struts for so long. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > James Mitchell > > > > > > > 678.910.8017 > > > > > > > Skpe: jmitchtx > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Nov 19, 2005, at 11:19 PM, Abrams, Howard A wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is there a release plan for 1.1.2? It seems there are a > > > > significant > > > > > > > > number of issues on the trunk; some of which may not be > > marked > > > > as > > > > > > > > such in JIRA. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, now that we've gotten passed the TCK, moved to SVN, > > and > > > > > > > > broken out the various sub projects, I'd like to revisit the > > > > > > > > subject of releasing the API/impl separately from the > > > > components. > > > > > > > > There are many of us who do not use any of the sub projects, > > so > > > > it > > > > > > > > seems silly to hold back a release of the impl due to a bug > > in > > > > some > > > > > > > > random fancy component. Any +1's out there? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > h. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
