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
