You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by David M Johnson <Da...@Sun.COM> on 2005/11/08 16:48:41 UTC
Planning for Roller 2.1 release
We've started talking about what we want to do for the Roller 2.1
releases and proposals are popping up on the wiki. Allen and I have
some feature commitments for December, so that would be a good time for
Roller release too. I'm still working on my proposals for this
release, but I went ahead and put together a page that summarizes our
current thinking.
http://www.rollerweblogger.org/wiki/Wiki.jsp?
page=Proposal_Roller_2.1_Release
Comments, suggestions and additional proposals (and offers of help) are
welcome.
- Dave
Re: Planning for Roller 2.1 release
Posted by paksegu <pa...@yahoo.com>.
I think we fare ocusing too much on release that it's starting to get in the way of creativity. We should go ahead with 1.3 release soon, followed by 2.0 release in december since codes have been already commited. once that is settled we can use 2.1 just to brain storm and possibly db scripts changes can be addressed here as well. This can set the stage for a smoother 3.0 release.
-Ransford
Dave Johnson <da...@rollerweblogger.org> wrote:
On Nov 9, 2005, at 3:18 AM, Miguel A Paraz wrote:
> On 11/8/05, David M Johnson wrote:
>> We've started talking about what we want to do for the Roller 2.1
>> releases and proposals are popping up on the wiki. Allen and I have
>> some feature commitments for December, so that would be a good time
>> for
>> Roller release too. I'm still working on my proposals for this
>> release, but I went ahead and put together a page that summarizes our
>> current thinking.
>
> Based on your post on the ROME mailing list, I guess you already have
> Atom 1.0 support on the list. I tried plugging in your
> rome-0.8-dave.jar without rebuilding, and I saw that getAuthor() is
> gone.
RIght.
I'm sticking with the official ROME v0.7 release for Roller 2.0.
I'm not comfortable releasing a hacked version of the ROME jar.
I hope to upgrade to ROME v0.8 in the 2.1 timeframe.
> I'm adding GeoInfo support for my
> own use. I added a subclass and a joined table for PlanetEntryData to
> hold the latitude/longitude data, and a ROME module for the new
> namespace.
>
> For proper parsing inside PlanetMangerImpl, I put:
>
> if (romeEntry.getModule(GeoModule.URI) == null) {
> entry = new PlanetEntryData(feed, romeEntry, sub);
> } else {
> entry = new R2PlanetEntryData(feed, romeEntry, sub); // my
> subclass with GeoInfo
> }
>
> If people want to add their own feed persistence subclasses based on
> ROME Modules, I believe it would be good to make this a plugin
> mechanism.
Good point.
- Dave
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
---------------------------------
Yahoo! FareChase - Search multiple travel sites in one click.
Re: Planning for Roller 2.1 release
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 9, 2005, at 3:18 AM, Miguel A Paraz wrote:
> On 11/8/05, David M Johnson <Da...@sun.com> wrote:
>> We've started talking about what we want to do for the Roller 2.1
>> releases and proposals are popping up on the wiki. Allen and I have
>> some feature commitments for December, so that would be a good time
>> for
>> Roller release too. I'm still working on my proposals for this
>> release, but I went ahead and put together a page that summarizes our
>> current thinking.
>
> Based on your post on the ROME mailing list, I guess you already have
> Atom 1.0 support on the list. I tried plugging in your
> rome-0.8-dave.jar without rebuilding, and I saw that getAuthor() is
> gone.
RIght.
I'm sticking with the official ROME v0.7 release for Roller 2.0.
I'm not comfortable releasing a hacked version of the ROME jar.
I hope to upgrade to ROME v0.8 in the 2.1 timeframe.
> I'm adding GeoInfo <http://esw.w3.org/topic/GeoInfo> support for my
> own use. I added a subclass and a joined table for PlanetEntryData to
> hold the latitude/longitude data, and a ROME module for the new
> namespace.
>
> For proper parsing inside PlanetMangerImpl, I put:
>
> if (romeEntry.getModule(GeoModule.URI) == null) {
> entry = new PlanetEntryData(feed, romeEntry, sub);
> } else {
> entry = new R2PlanetEntryData(feed, romeEntry, sub); // my
> subclass with GeoInfo
> }
>
> If people want to add their own feed persistence subclasses based on
> ROME Modules, I believe it would be good to make this a plugin
> mechanism.
Good point.
- Dave
Re: Planning for Roller 2.1 release
Posted by Miguel A Paraz <mp...@gmail.com>.
On 11/8/05, David M Johnson <Da...@sun.com> wrote:
> We've started talking about what we want to do for the Roller 2.1
> releases and proposals are popping up on the wiki. Allen and I have
> some feature commitments for December, so that would be a good time for
> Roller release too. I'm still working on my proposals for this
> release, but I went ahead and put together a page that summarizes our
> current thinking.
Based on your post on the ROME mailing list, I guess you already have
Atom 1.0 support on the list. I tried plugging in your
rome-0.8-dave.jar without rebuilding, and I saw that getAuthor() is
gone.
I'm adding GeoInfo <http://esw.w3.org/topic/GeoInfo> support for my
own use. I added a subclass and a joined table for PlanetEntryData to
hold the latitude/longitude data, and a ROME module for the new
namespace.
For proper parsing inside PlanetMangerImpl, I put:
if (romeEntry.getModule(GeoModule.URI) == null) {
entry = new PlanetEntryData(feed, romeEntry, sub);
} else {
entry = new R2PlanetEntryData(feed, romeEntry, sub); // my
subclass with GeoInfo
}
If people want to add their own feed persistence subclasses based on
ROME Modules, I believe it would be good to make this a plugin
mechanism.
Re: No schema changes *at all* in minor releases? (was Re: Planning for Roller 2.1 release)
Posted by Matt Raible <mr...@gmail.com>.
On 11/9/05, Dave Johnson <da...@rollerweblogger.org> wrote:
>
> On Nov 9, 2005, at 1:32 PM, Allen Gilliland wrote:
> > On Tue, 2005-11-08 at 20:52, Dave Johnson wrote:
> >> Did we really mean to completely forbid any database changes at all
> >> in minor releases? If so, comment moderation is going to have to wait
> >> for 3.0.
> >
> > yes, that was my intention, but that is partly predicated on the
> > belief that we want to stick to fairly regular releases. i like
> > developing very incrementally, which means smaller and more focused
> > features, and more frequent releases. if we do this then i don't
> > think we need to allow for db scripts on every release, only every 2-3
> > releases.
> >
> > i also like the convention of only applying upgrade scripts on major
> > releases. that way a user always knows that if it's an X.0.0 release
> > then there is db script that needs to be run. it also saves us some
> > work because the upgrade guides for minor releases can be small or
> > non-existent.
>
> I think the problem is that most the features requested for Roller
> require some form of schema change, so we'll either be deferring lots
> of features, like comment moderation (hi Linda!), or bumping up the
> major rev number a lot. So, we'll have Roller v26.3 in no time. Not a
> major issue, I guess, but I think we need to tweak something. For
> example, what if we did "Major.Minor.Patch" numbering and banned all
> database changes from patch releases instead?
+1
I think it's somewhat shortsighted to require version bumbs just for
schema changes.
>
> - Dave
>
>
Re: Proposed change to release plan (was Re: Planning for Roller 2.1 release)
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 10, 2005, at 12:48 PM, Allen Gilliland wrote:
> On Thu, 2005-11-10 at 06:41, Dave Johnson wrote:
>> On Nov 9, 2005, at 11:37 PM, Allen Gilliland wrote:
>> !! Release numbers and Versions
>> Release number convention is __major.feature.minor-patch__
>
> I think that's a bit confusing. Most other software uses
> Major.Minor.Patch, so I say we stick to that. The main reason being
> that I think it's a little misleading to offer 1.2.0 -> 1.2.1 as a
> release which could have some fairly significant changes. for example
> i am rewriting our presentation caching for the next release, and even
> though it doesn't require a schema change i wouldn't put it in a
> release called 2.0.1.
Confusing!?! That's what how the JDK numbering works! Hmmm... on second
thought, never-mind.
> I say we just go back to the old plan since we don't seem to like the
> idea of limiting db schema changes to major releases. That means we
> follow Major.Minor.Patch release numbering. Most releases will be
> Minor and may include small db changes which allow for rollbacks.
> Major releases can have bigger changes which may not be compatible
> with previous versions. In some extreme cases we'll offer patch
> releases, but I don't think they should be necessary.
>
> Is that cool? I guess it's basically the plan we have now, except
> that we are allowing db changes in minor releases as long as they are
> backwards compatible.
Cool. I think that's the consensus, based on Matt's +1 to patch
numbering and Elias wanting the possibility of tagging before 3.0. I
added the words "minor backwards compatible database schema changes" to
the description of a minor release and I think we're done with the
release plan discussion.
- Dave
Re: Proposed change to release plan (was Re: Planning for Roller 2.1
release)
Posted by Allen Gilliland <Al...@Sun.COM>.
On Thu, 2005-11-10 at 06:41, Dave Johnson wrote:
> On Nov 9, 2005, at 11:37 PM, Allen Gilliland wrote:
> > On Wed, 2005-11-09 at 11:18, Dave Johnson wrote:
> >> I think the problem is that most the features requested for Roller
> >> require some form of schema change, so we'll either be deferring lots
> >> of features, like comment moderation (hi Linda!), or bumping up the
> >> major rev number a lot. So, we'll have Roller v26.3 in no time. Not a
> >> major issue, I guess, but I think we need to tweak something. For
> >> example, what if we did "Major.Minor.Patch" numbering and banned all
> >> database changes from patch releases instead?
> >
> > well, it seems like this discussion has come full circle back to our
> > last discussion on development cycle and release conventions. my
> > feeling is that patch releases are useless when you have a reasonably
> > short development cycle. it makes sense for products to have patch
> > releases when they only plan to releases once a year, but if we are
> > releasing once every month or two then why do we need patch releases?
>
> Yes, the word "patch" does seem to indicate a no-new-feature, bug-fix
> release.
> So patch is the wrong word.
>
> And by the way, what remains to be done for the 2.0 database scripts?
last time i had tested the create script on postgres it spewed a whole bunch of errors. but if you've tested the latest against postgres and say it works then that's fine with me.
>
>
> > v26.3 in no time would require us to be especially short sited.
> > personally, i don't think it's that hard to lump together the database
> > changes so that we only have to do them once every 2-3 months. look at
> > how much trouble we've had with the Roller 2.0 db scripts. the code
> > base has been pretty much set for weeks now, but the db scripts are
> > still not complete. i prefer not to go through all of that for every
> > release.
>
> Totally agree. Ideally, monthly releases should be schema change free.
>
>
> > obviously it's not my intention to force people to put off the features
> > they want to develop, but i am also not convinced that we need to be
> > making db changes all the time. if you think we really need db changes
> > that frequently then go for it.
>
> Like I said, the problem is that now most feature changes require schema
> changes. At some point, when the database schema approaches completion,
> that should change.
>
> Here's my proposed change to the release plan. Replace the "Release
> numbers and Versions" section with this:
>
>
> !! Release numbers and Versions
>
> Release number convention is __major.feature.minor-patch__
>
> ! Major releases
> A major release is noted by a change in the major release number (i.e.
> 1.x to 2.x). Major releases contain larger than usual new features
> (e.g. group blogging) and larger than usual changes to the database
> schema, which are not guaranteed to be ''backwards compatible''. The
> upgrade procedure will be longer and more involved than a normal
> release.
>
> ! Feature releases
> A feature release is noted by a change in the feature release number
> (i.e. 1.2 to 1.3). Feature releases typically contain a half-dozen new
> features and minor ''backwards compatible'' database schema changes.
> Backwards compatible means that after you upgrade the schema for the
> new version of Roller, the old version of Roller will still work fine
> with the database.
>
> ! Minor releases
> A minor release is noted by a change in the minor release number (i.e.
> 1.2.0 to 1.2.1). Minor releases typically contain a half-dozen new
> features and are guaranteed to have NO database schema changes. Roller
> users should feel very comfortable about upgrading their roller
> installation with a new minor release.
>
> ! Emergency bug fix release
> We expect that each release of roller will simply be considered a minor
> release, however should something unfortunate happen and we must do an
> emergency bug fix for a given release then we may mark that release
> with an incremental version number (i.e. 1.3.1-0). This is not expected
> to happen often
I think that's a bit confusing. Most other software uses Major.Minor.Patch, so I say we stick to that. The main reason being that I think it's a little misleading to offer 1.2.0 -> 1.2.1 as a release which could have some fairly significant changes. for example i am rewriting our presentation caching for the next release, and even though it doesn't require a schema change i wouldn't put it in a release called 2.0.1.
I say we just go back to the old plan since we don't seem to like the idea of limiting db schema changes to major releases. That means we follow Major.Minor.Patch release numbering. Most releases will be Minor and may include small db changes which allow for rollbacks. Major releases can have bigger changes which may not be compatible with previous versions. In some extreme cases we'll offer patch releases, but I don't think they should be necessary.
Is that cool? I guess it's basically the plan we have now, except that we are allowing db changes in minor releases as long as they are backwards compatible.
-- Allen
Proposed change to release plan (was Re: Planning for Roller 2.1 release)
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 9, 2005, at 11:37 PM, Allen Gilliland wrote:
> On Wed, 2005-11-09 at 11:18, Dave Johnson wrote:
>> I think the problem is that most the features requested for Roller
>> require some form of schema change, so we'll either be deferring lots
>> of features, like comment moderation (hi Linda!), or bumping up the
>> major rev number a lot. So, we'll have Roller v26.3 in no time. Not a
>> major issue, I guess, but I think we need to tweak something. For
>> example, what if we did "Major.Minor.Patch" numbering and banned all
>> database changes from patch releases instead?
>
> well, it seems like this discussion has come full circle back to our
> last discussion on development cycle and release conventions. my
> feeling is that patch releases are useless when you have a reasonably
> short development cycle. it makes sense for products to have patch
> releases when they only plan to releases once a year, but if we are
> releasing once every month or two then why do we need patch releases?
Yes, the word "patch" does seem to indicate a no-new-feature, bug-fix
release.
So patch is the wrong word.
And by the way, what remains to be done for the 2.0 database scripts?
> v26.3 in no time would require us to be especially short sited.
> personally, i don't think it's that hard to lump together the database
> changes so that we only have to do them once every 2-3 months. look at
> how much trouble we've had with the Roller 2.0 db scripts. the code
> base has been pretty much set for weeks now, but the db scripts are
> still not complete. i prefer not to go through all of that for every
> release.
Totally agree. Ideally, monthly releases should be schema change free.
> obviously it's not my intention to force people to put off the features
> they want to develop, but i am also not convinced that we need to be
> making db changes all the time. if you think we really need db changes
> that frequently then go for it.
Like I said, the problem is that now most feature changes require schema
changes. At some point, when the database schema approaches completion,
that should change.
Here's my proposed change to the release plan. Replace the "Release
numbers and Versions" section with this:
!! Release numbers and Versions
Release number convention is __major.feature.minor-patch__
! Major releases
A major release is noted by a change in the major release number (i.e.
1.x to 2.x). Major releases contain larger than usual new features
(e.g. group blogging) and larger than usual changes to the database
schema, which are not guaranteed to be ''backwards compatible''. The
upgrade procedure will be longer and more involved than a normal
release.
! Feature releases
A feature release is noted by a change in the feature release number
(i.e. 1.2 to 1.3). Feature releases typically contain a half-dozen new
features and minor ''backwards compatible'' database schema changes.
Backwards compatible means that after you upgrade the schema for the
new version of Roller, the old version of Roller will still work fine
with the database.
! Minor releases
A minor release is noted by a change in the minor release number (i.e.
1.2.0 to 1.2.1). Minor releases typically contain a half-dozen new
features and are guaranteed to have NO database schema changes. Roller
users should feel very comfortable about upgrading their roller
installation with a new minor release.
! Emergency bug fix release
We expect that each release of roller will simply be considered a minor
release, however should something unfortunate happen and we must do an
emergency bug fix for a given release then we may mark that release
with an incremental version number (i.e. 1.3.1-0). This is not expected
to happen often
- Dave
Re: No schema changes *at all* in minor releases? (was Re: Planning
for Roller 2.1 release)
Posted by Allen Gilliland <Al...@Sun.COM>.
On Wed, 2005-11-09 at 11:18, Dave Johnson wrote:
> I think the problem is that most the features requested for Roller
> require some form of schema change, so we'll either be deferring lots
> of features, like comment moderation (hi Linda!), or bumping up the
> major rev number a lot. So, we'll have Roller v26.3 in no time. Not a
> major issue, I guess, but I think we need to tweak something. For
> example, what if we did "Major.Minor.Patch" numbering and banned all
> database changes from patch releases instead?
well, it seems like this discussion has come full circle back to our
last discussion on development cycle and release conventions. my
feeling is that patch releases are useless when you have a reasonably
short development cycle. it makes sense for products to have patch
releases when they only plan to releases once a year, but if we are
releasing once every month or two then why do we need patch releases?
v26.3 in no time would require us to be especially short sited.
personally, i don't think it's that hard to lump together the database
changes so that we only have to do them once every 2-3 months. look at
how much trouble we've had with the Roller 2.0 db scripts. the code
base has been pretty much set for weeks now, but the db scripts are
still not complete. i prefer not to go through all of that for every
release.
obviously it's not my intention to force people to put off the features
they want to develop, but i am also not convinced that we need to be
making db changes all the time. if you think we really need db changes
that frequently then go for it.
-- Allen
Re: No schema changes *at all* in minor releases? (was Re: Planning for Roller 2.1 release)
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 9, 2005, at 1:32 PM, Allen Gilliland wrote:
> On Tue, 2005-11-08 at 20:52, Dave Johnson wrote:
>> Did we really mean to completely forbid any database changes at all
>> in minor releases? If so, comment moderation is going to have to wait
>> for 3.0.
>
> yes, that was my intention, but that is partly predicated on the
> belief that we want to stick to fairly regular releases. i like
> developing very incrementally, which means smaller and more focused
> features, and more frequent releases. if we do this then i don't
> think we need to allow for db scripts on every release, only every 2-3
> releases.
>
> i also like the convention of only applying upgrade scripts on major
> releases. that way a user always knows that if it's an X.0.0 release
> then there is db script that needs to be run. it also saves us some
> work because the upgrade guides for minor releases can be small or
> non-existent.
I think the problem is that most the features requested for Roller
require some form of schema change, so we'll either be deferring lots
of features, like comment moderation (hi Linda!), or bumping up the
major rev number a lot. So, we'll have Roller v26.3 in no time. Not a
major issue, I guess, but I think we need to tweak something. For
example, what if we did "Major.Minor.Patch" numbering and banned all
database changes from patch releases instead?
- Dave
Re: No schema changes *at all* in minor releases? (was Re: Planning
for Roller 2.1 release)
Posted by Allen Gilliland <Al...@Sun.COM>.
On Tue, 2005-11-08 at 20:52, Dave Johnson wrote:
>
> For a minor release:
> 1) there is no need for a long-running database upgrade script that
> could
> cause a site to have a significant downtime during the upgrade.
> 2) after the upgrade from X.A to X.B, it should be possible to revert to
> the X.A release and it will still work. In other words, the old release
> will work fine with the new release's database.
yep. in my mind i hadn't add the "long-running" part for #1. my feeling is just that an upgrade is just *that* much easier when you don't even have to think about running a db script. just drop in a new WAR file (once we get there) and you're done.
>
> Roller 2.0 is a major release, because it fails both tests (and it adds
> major
> new features). It requires a long-running upgrade script (although, you
> did
> speed it up significantly). And, once group blogging is turned on, it's
> not really
> possible to back off to a 1.X release.
>
> Did we really mean to completely forbid any database changes at all
> in minor releases? If so, comment moderation is going to have to wait
> for 3.0.
yes, that was my intention, but that is partly predicated on the belief that we want to stick to fairly regular releases. i like developing very incrementally, which means smaller and more focused features, and more frequent releases. if we do this then i don't think we need to allow for db scripts on every release, only every 2-3 releases.
i also like the convention of only applying upgrade scripts on major releases. that way a user always knows that if it's an X.0.0 release then there is db script that needs to be run. it also saves us some work because the upgrade guides for minor releases can be small or non-existent.
>
>
> > 3. the part about the CommentNotificationTask seems potentially
> > overkill
> > to me. I don't really see any reason why those emails can't go out as
> > the comments/trackbacks happen.
>
> A user asked for that specific feature, but I think you're right, its a
> "nice to have."
>
>
> >> <http://rollerweblogger.org/wiki/Wiki.jsp?
> >> page=Proposal_TrackbackVerification>
> >
> > same thing with modifying the roller_weblogcomments table for this one.
> > i think it would be okay if the for roller 2.1 there wasn't an offline
> > option, so you had to use the "live" method. then we can add the
> > offline option with roller 3.0
>
> I guess, considering the frequency of trackbacks, we could survive with
> live.
I also really like your throttling idea. It's tough to say how valuable throttling would be without doing some log analysis to determine if a series of trackback spams really does come in quick batches.
-- Allen
>
> - Dave
>
No schema changes *at all* in minor releases? (was Re: Planning for Roller 2.1 release)
Posted by Dave Johnson <da...@rollerweblogger.org>.
On Nov 8, 2005, at 10:03 PM, Allen Gilliland wrote:
> On Tue, 2005-11-08 at 14:37, Dave Johnson wrote:
>> I've got first cuts of three of my 2.1 features ready for review:
>> <http://rollerweblogger.org/wiki/Wiki.jsp?
>> page=Proposal_CommentManagementAndModeration>
>
> 1. you mention the "comment.moderation.enabled" property, which would
> allow a site admin to enable/disable comment moderation for the whole
> site, but what about allowing users to enable/disable comment
> moderation
> on a per weblog basis? this is especially important for large sites
> which may want to give their bloggers the option of comment moderation,
> but not force it.
Yes, that should really be per-weblog. I left that out because I was
thinking
about your point #2 below. Currently, weblog-level config changes
require
new fields in the website table.
> 2. you talk about adding fields to the website and
> roller_weblogcomments
> table, but that means db changes, which would meant these changes would
> not be possible until roller 3.0.
When I wrote this I had just changed my mind and decided that maybe
minor
schema changes are allowed in minor releases after all. What was I
thinking?
The reason to limit schema changes in minor releases is to make sure
that minor releases are easy and easy to back out of. That means two
things:
For a minor release:
1) there is no need for a long-running database upgrade script that
could
cause a site to have a significant downtime during the upgrade.
2) after the upgrade from X.A to X.B, it should be possible to revert to
the X.A release and it will still work. In other words, the old release
will work fine with the new release's database.
Roller 2.0 is a major release, because it fails both tests (and it adds
major
new features). It requires a long-running upgrade script (although, you
did
speed it up significantly). And, once group blogging is turned on, it's
not really
possible to back off to a 1.X release.
Did we really mean to completely forbid any database changes at all
in minor releases? If so, comment moderation is going to have to wait
for 3.0.
> 3. the part about the CommentNotificationTask seems potentially
> overkill
> to me. I don't really see any reason why those emails can't go out as
> the comments/trackbacks happen.
A user asked for that specific feature, but I think you're right, its a
"nice to have."
>> <http://rollerweblogger.org/wiki/Wiki.jsp?
>> page=Proposal_TrackbackVerification>
>
> same thing with modifying the roller_weblogcomments table for this one.
> i think it would be okay if the for roller 2.1 there wasn't an offline
> option, so you had to use the "live" method. then we can add the
> offline option with roller 3.0
I guess, considering the frequency of trackbacks, we could survive with
live.
- Dave
Re: Planning for Roller 2.1 release
Posted by Allen Gilliland <Al...@Sun.COM>.
On Tue, 2005-11-08 at 14:37, Dave Johnson wrote:
> I've got first cuts of three of my 2.1 features ready for review:
>
> <http://rollerweblogger.org/wiki/Wiki.jsp?
> page=Proposal_CommentManagementAndModeration>
Everything here looks good to me, but I have a few comments ...
1. you mention the "comment.moderation.enabled" property, which would
allow a site admin to enable/disable comment moderation for the whole
site, but what about allowing users to enable/disable comment moderation
on a per weblog basis? this is especially important for large sites
which may want to give their bloggers the option of comment moderation,
but not force it.
2. you talk about adding fields to the website and roller_weblogcomments
table, but that means db changes, which would meant these changes would
not be possible until roller 3.0.
3. the part about the CommentNotificationTask seems potentially overkill
to me. I don't really see any reason why those emails can't go out as
the comments/trackbacks happen.
> <http://rollerweblogger.org/wiki/Wiki.jsp?
> page=Proposal_TrackbackVerification>
same thing with modifying the roller_weblogcomments table for this one.
i think it would be okay if the for roller 2.1 there wasn't an offline
option, so you had to use the "live" method. then we can add the
offline option with roller 3.0
> <http://rollerweblogger.org/wiki/Wiki.jsp?
> page=Proposal_UnifiedBlacklistManagement>
looks good to me.
-- Allen
>
> Let's get small. Here's the corresponding Tiny URLs:
>
> http://tinyurl.com/bq8l7 - comment mod and mgmt
> http://tinyurl.com/b8xrr - trackback verification
> http://tinyurl.com/a4z8y - blacklist mgmt
>
> As usual: comments, suggestions, etc. welcome.
>
> - Dave
>
>
> On Nov 8, 2005, at 10:48 AM, David M Johnson wrote:
>
> > We've started talking about what we want to do for the Roller 2.1
> > releases and proposals are popping up on the wiki. Allen and I have
> > some feature commitments for December, so that would be a good time
> > for Roller release too. I'm still working on my proposals for this
> > release, but I went ahead and put together a page that summarizes our
> > current thinking.
> >
> > http://www.rollerweblogger.org/wiki/Wiki.jsp?
> > page=Proposal_Roller_2.1_Release
> >
> > Comments, suggestions and additional proposals (and offers of help)
> > are welcome.
> >
> > - Dave
> >
>
Re: Planning for Roller 2.1 release
Posted by Dave Johnson <da...@rollerweblogger.org>.
I've got first cuts of three of my 2.1 features ready for review:
<http://rollerweblogger.org/wiki/Wiki.jsp?
page=Proposal_CommentManagementAndModeration>
<http://rollerweblogger.org/wiki/Wiki.jsp?
page=Proposal_TrackbackVerification>
<http://rollerweblogger.org/wiki/Wiki.jsp?
page=Proposal_UnifiedBlacklistManagement>
Let's get small. Here's the corresponding Tiny URLs:
http://tinyurl.com/bq8l7 - comment mod and mgmt
http://tinyurl.com/b8xrr - trackback verification
http://tinyurl.com/a4z8y - blacklist mgmt
As usual: comments, suggestions, etc. welcome.
- Dave
On Nov 8, 2005, at 10:48 AM, David M Johnson wrote:
> We've started talking about what we want to do for the Roller 2.1
> releases and proposals are popping up on the wiki. Allen and I have
> some feature commitments for December, so that would be a good time
> for Roller release too. I'm still working on my proposals for this
> release, but I went ahead and put together a page that summarizes our
> current thinking.
>
> http://www.rollerweblogger.org/wiki/Wiki.jsp?
> page=Proposal_Roller_2.1_Release
>
> Comments, suggestions and additional proposals (and offers of help)
> are welcome.
>
> - Dave
>