I agree. One area where I would change things would be the bug part. I think we should just reference JIRA there.
In the future, I am hoping we can get the size of the bug list under control. Once that happens we could sort the bugs out into the upcoming release number and a TBD. So bugs that were crucial for fixes in the upcoming release could be identified. sean On 8/2/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Count me in! > > +1 for a release plan, but not as detailed, I would say - listing a 100 > bugs is not so informative, I'd say. > > regards, > > Martin > > > On 8/2/05, Bruno Aranda <[EMAIL PROTECTED]> wrote: > > +1 We need to put some order in the releases so it is more clear what > > the objective of the release is and if the objectives are fullfilled. > > As for the next release version I would also use the 1.0.10 for the > > same reasons... > > I have no experience in this stuff, but of course, I am always open to > > learning, although next week I am leaving for three weeks on vacation > > to the Norht-eastern USA / Canada ;-) and I will don't have access to > > the internet (I just need to disconnect a while from computers and > > come with fresh ideas after vacation ;-) )... > > I've looked at the release plans for struts/shale and we definitely > > need to do something like that! > > > > Regards, > > > > Bruno > > > > 2005/8/2, Craig McClanahan <[EMAIL PROTECTED]>: > > > On 8/1/05, Sean Schofield <[EMAIL PROTECTED] > wrote: > > > > > > > > I also think we should have a release plan. I just saw the Shale > > > > release plan > (http://wiki.apache.org/struts/ShaleRelease100 ) and I > > > > think we should "rip" Craig's release plan and use it as a foundation > > > > for our own. This is how the serious ASF projects do things and I > > > > think with each release we should be trying to be aligning ourselves > > > > more and more with the ASF standards onthese sorts of things. > > > > > > > > Thoughts? > > > > > > > > > > Doing something like this is definitely a good idea, but you are > > > giving me too much credit :-). The Struts release managers (James, > > > Martin, et. al.) have been following this sort of disciplined approach > > > at least back into the 1.2.2 days, and they deserve the credit for > > > formalizing a checklist like this for release managers to follow. > > > > > > http://wiki.apache.org/struts/StrutsReleasePlans > > > > > > > sean > > > > > > Craig > > > > > > >
