I agree with Allen's comments that we would need a proposal before we start committing our work. I have just been really busy and haven't had time to do so, but I'll ask folks in my team for help on the proposal. We will definitely be asking for instructions once we are ready to start working on the roller_3.x branch.
Regards, Elias On 11/7/05, Dave Johnson <[EMAIL PROTECTED]> wrote: > I think Allen's right, we should have a plan for tagging. Or, if you > already have code ready to commit for it, a write up that details the > changes. > > I just wanted to point out that, once you're ready to start your tag > work, you could do it in the roller_3.x branch. Don't let the Roller > releases hold you up. Keep trunk -> roller_3.x in sync periodically > (weekly maybe) and then do your internal deployments off of roller_3.x. > At Roller 3.0 release time, Roller 3.0 would become the trunk. That 's > what we did with 2.0. > > This is the standing release/branching plan: > http://rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan > > - Dave > > > > On Nov 2, 2005, at 3:36 PM, Allen Gilliland wrote: > > > On Wed, 2005-11-02 at 12:25, Dave Johnson wrote: > >> On Nov 2, 2005, at 12:52 PM, Elias Torres wrote: > >>> We have a sample tag implementation started/running in our internal > >>> pilot development environment and was wondering if we still have time > >>> to sneak in a table before 2.0 is official. If we could do that we > >>> could have tagging at some point in 2.x and won't have to wait til > >>> 3.0. What do you all think? > >> > >> I'm OK with this, because it would be an unused table, easy to > >> change/upgrade later. What does the table look like? > >> > > > > I am actually a mixed bag on this right now. We still haven't seen an > > actual proposal on how tag support would be implemented and I wouldn't > > feel comfortable approving this blindly. > > > > I hope I am not sound too anal about the proposals, but I think it's > > in the best interest of the project if everyone has a chance to review > > a proposed implementation before making any significant changes. > > > > Also note that there really doesn't need to be any reason to rush > > unless you truly feel that your implementation is almost done, which > > again would be weird since we haven't seen a proposal. We can decide > > to move to a new major version at any time as long as everyone is > > agreed. That means that we can go from Roller 2.1 to Roller 3.0 as > > far as I'm concerned. The purpose of limiting db changes to major > > release upgrades was not to make it harder on us to change the db, but > > rather to make it easier on users to upgrade. > > > > -- Allen > > > > > >> > >>> Also, is it ok for me to commit some small changes such as trackback > >>> security (limiting trackbacks to URL patterns in roller.properties) > >>> optional of course and other small fixes to DB2/Derby to the trunk. > >>> We > >>> are currently using a custom build internally where we maintain > >>> patches to a specific revision number, therefore I'm trying to reduce > >>> the number of patches to a minimum. > >> > >> I'm committed your trackback security change already, so I assume > >> you're talking about a fix to that? If that's the case then go right > >> ahead. > >> > >> - Dave > >> > >> > >>> > >>> Regards, > >>> > >>> Elias > >>> > >> > > > >
