Re: [openFIRST-devel] Interim release
Brought to you by:
xtimg
From: Jamie B. <ast...@gm...> - 2005-08-24 18:12:27
|
I have created a branch in CVS called REL1_1_BRANCH for this interim release. It starts at the last release date (April 14, 2004 for everything except awards and emoticon, which are April 12, 2004). Any bugs that were fixed after that date must be commited to that branch. Any new bugs found in this branch should have the version 1.1 (1.1.0 will be the release). Any current bugs that have not been fixed in REL1_1_BRANCH have the keyword REL1_1. (I'm currently working on tagging bugs). The modules bashinstall, config, config_asp, logger_asp, modules, update, and www are excluded from all of the above. On 8/23/05, Tim Ginn <ti...@op...> wrote: > This is a post to the openFIRST discussion list, subscription management = information is included at the bottom of this message. > _______________________________________________ >=20 > On 23-Aug-05, at 4:37 PM, Jamie Bliss wrote: >=20 > > Because the next release is going to be massive, I'm wondering if we > > should have an interim release, for 2 reasons: > > - To ease the transition > > - To quench the parched masses ;) >=20 > I think that's a good idea. I'd like to see the simple Bugzilla bugs > which are still open for assorted modules fixed, too (I'm sure one of > the newer people could take this on as most of them are quick things to > fix properly). >=20 > > Some of the things I'm thinking should go in there is the file > > structure changes and the new DB object. >=20 > I like that idea; were you thinking of having the DB object there as a > required thing that's used by all the code, or being there for the > benefit of people with custom applications to give them an opportunity > to migrate? I think as an interim release intended to ease the > transition having it there but not required or necessarily used by > everything would be helpful (e.g. no massive rewrites to every module > just to have it work, etc.). >=20 > > We could also toss in the > > older dev module system (the one bassed on openfirst.info.php), since > > that is considerably simpler than the XML one we're working on > > currently. >=20 > I'm not a big fan of tossing in the older dev module system that's > based on openfirst.info.php-- the last released version (which was a > while ago) doesn't use it and I don't see the point in having people > migrate to it in the interim and then away from it when the next full > release comes out. If we don't formally release anything using > openfirst.info.php we'll never have to worry about officially > supporting it in the future and maintaining some semblance of > compatibility which I think would simplify our lives considerably in > the future (especially since there is no Support Coordinator at the > present time). >=20 > > Anybody up to this? >=20 > By all means; I could use the practice packaging another release (it's > been a while) and may even end up writing some new tools to help me out > (reference: BZ id #243). >=20 >=20 > Tim >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >=20 >=20 > _______________________________________________ > openFIRST-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openfirst-devel >=20 --=20 Jamie ------------------------------------------------------------------- http://endeavour.zapto.org/astro73/ Thank you to JosephM for inviting me to Gmail! Have lots of invites. Gmail now has 2GB. |