You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Anil Gangolli <an...@busybuddha.org> on 2005/08/14 19:44:38 UTC
note: db upgrade for 1.3
I've started the db upgrade script for 1.3. I had only one minor change to fix a column name that conflicts with a keyword in MySQL 5.x. See ROL-754.
If you build from latest on trunk (SVN revision 232624 or higher), you will need to apply the 120-to-130-migration.sql script (or rebuild your db from scratch).
--a
Re: note: db upgrade for 1.3
Posted by Anil Gangolli <an...@busybuddha.org>.
These changes are now (exclusively) on the Roller 2.0 branch.
http://svn.apache.org/viewcvs?rev=233011&view=rev
Apologies.
--a.
p.s. I admit an error of judgement in this case. I am still not OK with the blanket "db changes only in major release revisions"
proposal.
----- Original Message -----
From: "Anil Gangolli" <an...@busybuddha.org>
To: <ro...@incubator.apache.org>; <ma...@raibledesigns.com>
Sent: Tuesday, August 16, 2005 8:10 AM
Subject: Re: note: db upgrade for 1.3
>
> For those working on trunk:
>
> Revision 233006 backs the db changes related to ROL-754 out of trunk.
>
> For those working on the Roller 2.0 branch:
>
> I will be putting these on the Roller 2.0 branch in the next day or two.
>
> --a.
>
>
> ----- Original Message -----
> From: "Anil Gangolli" <an...@busybuddha.org>
> To: <ro...@incubator.apache.org>; <ma...@raibledesigns.com>
> Sent: Tuesday, August 16, 2005 7:55 AM
> Subject: Re: note: db upgrade for 1.3
>
>
>>
>> That's a valid point; I'll back these changes out of trunk in the next day or two.
>>
>> I am, on the other hand, not yet convinced of the new release plan (proposed in
>> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan).
>>
>> I'd like more discussion, and I'd like to see it itemized in the same way as the earlier
>> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ReleaseNumberingConvention that Dave had written up and I had edited.
>>
>> Reserving even minor database changes to major releases will stunt progress or will cause major release numbers to advance quite
>> rapidly. This would have put us at Roller 5.x or 6.x by this point, which is certainly ok, but there are other implied semantics
>> that people associate with major release numbers; arguably, we're somewhat more stabilized now, but not every db change is
>> equivalently difficult and risky.
>>
>> --a.
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> From: "Matt Raible" <mr...@gmail.com>
>> To: <ro...@incubator.apache.org>
>> Sent: Tuesday, August 16, 2005 7:43 AM
>> Subject: Re: note: db upgrade for 1.3
>>
>>
>>> In this particular case, I'm -1 on this change. It's to avoid an
>>> error with MySQL 5, and my guess is most people aren't using this
>>> database. It's good to look ahead and plan ahead, but I think it's
>>> more important to worry about existing users - who are likely on an
>>> older version of MySQL and don't like to run database upgrade scripts.
>>>
>>> Matt
>>>
>>> On 8/16/05, Anil Gangolli <an...@busybuddha.org> wrote:
>>>>
>>>> I believe this is consistent with the conventions we had *earlier* agreed on in
>>>> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ReleaseNumberingConvention
>>>>
>>>> I think it would be a bad idea to prohibit all db schema changes to full major X.0 versions. We've so far used X.Y versions
>>>> for
>>>> these, and avoided including them in X.Y.Z versions. Alfternatively, the full major number is going to jump much more rapidly.
>>>>
>>>> If everyone else is in agreement, however, I will back out the code change.
>>>>
>>>> At this point, it is on trunk, so you must let me know.
>>>> --a.
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Allen Gilliland" <Al...@Sun.COM>
>>>> To: "roller-dev" <ro...@incubator.apache.org>
>>>> Sent: Monday, August 15, 2005 9:42 AM
>>>> Subject: Re: note: db upgrade for 1.3
>>>>
>>>>
>>>> > So, based on the new release plan which I believe we have mostly agreed on, this change to the schema should be reserved for
>>>> > a
>>>> > major release (i.e. 2.0).
>>>> >
>>>> > can we hold off on this db upgrade for the 1.3 release?
>>>> >
>>>> > -- Allen
>>>> >
>>>> >
>>>> > On Sun, 2005-08-14 at 10:44, Anil Gangolli wrote:
>>>> >> I've started the db upgrade script for 1.3. I had only one minor change to fix a column name that conflicts with a keyword
>>>> >> in
>>>> >> MySQL 5.x. See ROL-754.
>>>> >>
>>>> >> If you build from latest on trunk (SVN revision 232624 or higher), you will need to apply the 120-to-130-migration.sql
>>>> >> script (or
>>>> >> rebuild your db from scratch).
>>>> >>
>>>> >> --a
>>>> >
>>>>
>>>>
Re: note: db upgrade for 1.3
Posted by Anil Gangolli <an...@busybuddha.org>.
For those working on trunk:
Revision 233006 backs the db changes related to ROL-754 out of trunk.
For those working on the Roller 2.0 branch:
I will be putting these on the Roller 2.0 branch in the next day or two.
--a.
----- Original Message -----
From: "Anil Gangolli" <an...@busybuddha.org>
To: <ro...@incubator.apache.org>; <ma...@raibledesigns.com>
Sent: Tuesday, August 16, 2005 7:55 AM
Subject: Re: note: db upgrade for 1.3
>
> That's a valid point; I'll back these changes out of trunk in the next day or two.
>
> I am, on the other hand, not yet convinced of the new release plan (proposed in
> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan).
>
> I'd like more discussion, and I'd like to see it itemized in the same way as the earlier
> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ReleaseNumberingConvention that Dave had written up and I had edited.
>
> Reserving even minor database changes to major releases will stunt progress or will cause major release numbers to advance quite
> rapidly. This would have put us at Roller 5.x or 6.x by this point, which is certainly ok, but there are other implied semantics
> that people associate with major release numbers; arguably, we're somewhat more stabilized now, but not every db change is
> equivalently difficult and risky.
>
> --a.
>
>
>
>
>
> ----- Original Message -----
> From: "Matt Raible" <mr...@gmail.com>
> To: <ro...@incubator.apache.org>
> Sent: Tuesday, August 16, 2005 7:43 AM
> Subject: Re: note: db upgrade for 1.3
>
>
>> In this particular case, I'm -1 on this change. It's to avoid an
>> error with MySQL 5, and my guess is most people aren't using this
>> database. It's good to look ahead and plan ahead, but I think it's
>> more important to worry about existing users - who are likely on an
>> older version of MySQL and don't like to run database upgrade scripts.
>>
>> Matt
>>
>> On 8/16/05, Anil Gangolli <an...@busybuddha.org> wrote:
>>>
>>> I believe this is consistent with the conventions we had *earlier* agreed on in
>>> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ReleaseNumberingConvention
>>>
>>> I think it would be a bad idea to prohibit all db schema changes to full major X.0 versions. We've so far used X.Y versions for
>>> these, and avoided including them in X.Y.Z versions. Alfternatively, the full major number is going to jump much more rapidly.
>>>
>>> If everyone else is in agreement, however, I will back out the code change.
>>>
>>> At this point, it is on trunk, so you must let me know.
>>> --a.
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Allen Gilliland" <Al...@Sun.COM>
>>> To: "roller-dev" <ro...@incubator.apache.org>
>>> Sent: Monday, August 15, 2005 9:42 AM
>>> Subject: Re: note: db upgrade for 1.3
>>>
>>>
>>> > So, based on the new release plan which I believe we have mostly agreed on, this change to the schema should be reserved for a
>>> > major release (i.e. 2.0).
>>> >
>>> > can we hold off on this db upgrade for the 1.3 release?
>>> >
>>> > -- Allen
>>> >
>>> >
>>> > On Sun, 2005-08-14 at 10:44, Anil Gangolli wrote:
>>> >> I've started the db upgrade script for 1.3. I had only one minor change to fix a column name that conflicts with a keyword
>>> >> in
>>> >> MySQL 5.x. See ROL-754.
>>> >>
>>> >> If you build from latest on trunk (SVN revision 232624 or higher), you will need to apply the 120-to-130-migration.sql script
>>> >> (or
>>> >> rebuild your db from scratch).
>>> >>
>>> >> --a
>>> >
>>>
>>>
Re: note: db upgrade for 1.3
Posted by Allen Gilliland <Al...@Sun.COM>.
On Tue, 2005-08-16 at 08:50, Lance Lavandowska wrote:
> I think we should avoid a blanket statement of "no db changes except
> for major revisions" and instead opt for a concensus on changes. It
> may be that a database change is warranted (to fix a particularly
> grievious bug) in a minor version change.
So, I'm going to defend the opposite argument that we absolutely should be able to enforce "no db changes except on major versions." In my mind *if* we are a mature product then we should very seldomly need db changes and when we do need them we should group them together to make it easier on users.
I don't see how our progress will be stunted by holding db changes to major releases. We already said that major releases are flexible, but would run roughly once every 3-4 months. So if we need 3.0 after 2.1 then fine, we do it.
It's possible that our major rel numbers will go up faster, but again, we are supposed to be a mature product and that means our schema should be stable by now. I fully believe that we shouldn't need to change the schema more often than once every 3-4 months. If we do then we are just making things hard on our users and that sucks.
That being said, I fully agree with Lance and Anil that group concensus should be the real determining factor when deciding about db updates. If we feel that a db change is truely needed then we do it.
I don't want it to feel like our release plan is set in stone and cannot be changed. I think it is simply meant to be a guideline which lays out what we plan to do in most cases.
-- Allen
>
> As in this case, the change is not warranted for immediate release.
> Still, we may want to publish an Advisory to the wiki. Here we should
> add a note to the MySql page that users of MySql 5 will want to run a
> migration script and possibly replace some code (include as
> attachments). And add a note to the bug report pointing to the
> Advisory.
>
> That is all to say that we as a group should weigh any proposed db
> change and in which future release it should be included. The goal
> being to reduce the amount of work when upgrading to a new release.
>
> Lance
Re: note: db upgrade for 1.3
Posted by Lance Lavandowska <la...@gmail.com>.
I think we should avoid a blanket statement of "no db changes except
for major revisions" and instead opt for a concensus on changes. It
may be that a database change is warranted (to fix a particularly
grievious bug) in a minor version change.
As in this case, the change is not warranted for immediate release.
Still, we may want to publish an Advisory to the wiki. Here we should
add a note to the MySql page that users of MySql 5 will want to run a
migration script and possibly replace some code (include as
attachments). And add a note to the bug report pointing to the
Advisory.
That is all to say that we as a group should weigh any proposed db
change and in which future release it should be included. The goal
being to reduce the amount of work when upgrading to a new release.
Lance
Re: note: db upgrade for 1.3
Posted by Anil Gangolli <an...@busybuddha.org>.
That's a valid point; I'll back these changes out of trunk in the next day or two.
I am, on the other hand, not yet convinced of the new release plan (proposed in
http://www.rollerweblogger.org/wiki/Wiki.jsp?page=RollerReleasePlan).
I'd like more discussion, and I'd like to see it itemized in the same way as the earlier
http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ReleaseNumberingConvention that Dave had written up and I had edited.
Reserving even minor database changes to major releases will stunt progress or will cause major release numbers to advance quite
rapidly. This would have put us at Roller 5.x or 6.x by this point, which is certainly ok, but there are other implied semantics
that people associate with major release numbers; arguably, we're somewhat more stabilized now, but not every db change is
equivalently difficult and risky.
--a.
----- Original Message -----
From: "Matt Raible" <mr...@gmail.com>
To: <ro...@incubator.apache.org>
Sent: Tuesday, August 16, 2005 7:43 AM
Subject: Re: note: db upgrade for 1.3
> In this particular case, I'm -1 on this change. It's to avoid an
> error with MySQL 5, and my guess is most people aren't using this
> database. It's good to look ahead and plan ahead, but I think it's
> more important to worry about existing users - who are likely on an
> older version of MySQL and don't like to run database upgrade scripts.
>
> Matt
>
> On 8/16/05, Anil Gangolli <an...@busybuddha.org> wrote:
>>
>> I believe this is consistent with the conventions we had *earlier* agreed on in
>> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ReleaseNumberingConvention
>>
>> I think it would be a bad idea to prohibit all db schema changes to full major X.0 versions. We've so far used X.Y versions for
>> these, and avoided including them in X.Y.Z versions. Alfternatively, the full major number is going to jump much more rapidly.
>>
>> If everyone else is in agreement, however, I will back out the code change.
>>
>> At this point, it is on trunk, so you must let me know.
>> --a.
>>
>>
>>
>>
>> ----- Original Message -----
>> From: "Allen Gilliland" <Al...@Sun.COM>
>> To: "roller-dev" <ro...@incubator.apache.org>
>> Sent: Monday, August 15, 2005 9:42 AM
>> Subject: Re: note: db upgrade for 1.3
>>
>>
>> > So, based on the new release plan which I believe we have mostly agreed on, this change to the schema should be reserved for a
>> > major release (i.e. 2.0).
>> >
>> > can we hold off on this db upgrade for the 1.3 release?
>> >
>> > -- Allen
>> >
>> >
>> > On Sun, 2005-08-14 at 10:44, Anil Gangolli wrote:
>> >> I've started the db upgrade script for 1.3. I had only one minor change to fix a column name that conflicts with a keyword in
>> >> MySQL 5.x. See ROL-754.
>> >>
>> >> If you build from latest on trunk (SVN revision 232624 or higher), you will need to apply the 120-to-130-migration.sql script
>> >> (or
>> >> rebuild your db from scratch).
>> >>
>> >> --a
>> >
>>
>>
Re: note: db upgrade for 1.3
Posted by Matt Raible <mr...@gmail.com>.
In this particular case, I'm -1 on this change. It's to avoid an
error with MySQL 5, and my guess is most people aren't using this
database. It's good to look ahead and plan ahead, but I think it's
more important to worry about existing users - who are likely on an
older version of MySQL and don't like to run database upgrade scripts.
Matt
On 8/16/05, Anil Gangolli <an...@busybuddha.org> wrote:
>
> I believe this is consistent with the conventions we had *earlier* agreed on in
> http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ReleaseNumberingConvention
>
> I think it would be a bad idea to prohibit all db schema changes to full major X.0 versions. We've so far used X.Y versions for
> these, and avoided including them in X.Y.Z versions. Alfternatively, the full major number is going to jump much more rapidly.
>
> If everyone else is in agreement, however, I will back out the code change.
>
> At this point, it is on trunk, so you must let me know.
> --a.
>
>
>
>
> ----- Original Message -----
> From: "Allen Gilliland" <Al...@Sun.COM>
> To: "roller-dev" <ro...@incubator.apache.org>
> Sent: Monday, August 15, 2005 9:42 AM
> Subject: Re: note: db upgrade for 1.3
>
>
> > So, based on the new release plan which I believe we have mostly agreed on, this change to the schema should be reserved for a
> > major release (i.e. 2.0).
> >
> > can we hold off on this db upgrade for the 1.3 release?
> >
> > -- Allen
> >
> >
> > On Sun, 2005-08-14 at 10:44, Anil Gangolli wrote:
> >> I've started the db upgrade script for 1.3. I had only one minor change to fix a column name that conflicts with a keyword in
> >> MySQL 5.x. See ROL-754.
> >>
> >> If you build from latest on trunk (SVN revision 232624 or higher), you will need to apply the 120-to-130-migration.sql script (or
> >> rebuild your db from scratch).
> >>
> >> --a
> >
>
>
Re: note: db upgrade for 1.3
Posted by Anil Gangolli <an...@busybuddha.org>.
I believe this is consistent with the conventions we had *earlier* agreed on in
http://www.rollerweblogger.org/wiki/Wiki.jsp?page=Proposal_ReleaseNumberingConvention
I think it would be a bad idea to prohibit all db schema changes to full major X.0 versions. We've so far used X.Y versions for
these, and avoided including them in X.Y.Z versions. Alfternatively, the full major number is going to jump much more rapidly.
If everyone else is in agreement, however, I will back out the code change.
At this point, it is on trunk, so you must let me know.
--a.
----- Original Message -----
From: "Allen Gilliland" <Al...@Sun.COM>
To: "roller-dev" <ro...@incubator.apache.org>
Sent: Monday, August 15, 2005 9:42 AM
Subject: Re: note: db upgrade for 1.3
> So, based on the new release plan which I believe we have mostly agreed on, this change to the schema should be reserved for a
> major release (i.e. 2.0).
>
> can we hold off on this db upgrade for the 1.3 release?
>
> -- Allen
>
>
> On Sun, 2005-08-14 at 10:44, Anil Gangolli wrote:
>> I've started the db upgrade script for 1.3. I had only one minor change to fix a column name that conflicts with a keyword in
>> MySQL 5.x. See ROL-754.
>>
>> If you build from latest on trunk (SVN revision 232624 or higher), you will need to apply the 120-to-130-migration.sql script (or
>> rebuild your db from scratch).
>>
>> --a
>
Re: note: db upgrade for 1.3
Posted by Allen Gilliland <Al...@Sun.COM>.
So, based on the new release plan which I believe we have mostly agreed on, this change to the schema should be reserved for a major release (i.e. 2.0).
can we hold off on this db upgrade for the 1.3 release?
-- Allen
On Sun, 2005-08-14 at 10:44, Anil Gangolli wrote:
> I've started the db upgrade script for 1.3. I had only one minor change to fix a column name that conflicts with a keyword in MySQL 5.x. See ROL-754.
>
> If you build from latest on trunk (SVN revision 232624 or higher), you will need to apply the 120-to-130-migration.sql script (or rebuild your db from scratch).
>
> --a