Re: No schema changes *at all* in minor releases? (was Re: Planning for Roller 2.1 release)

[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: Proposed change to release plan (was Re: Planning for Roller 2.1 release)

[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)

[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)

[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