Re: [Evolution-hackers] Use real version in /apps/evolution/last_version
On Thu, 2010-12-02 at 15:25 +0100, Milan Crha wrote: > I would use the last version in the migration code check, and if any fix > in the migration routine would be done after another release, then just > increase the number in the version check. It might work as long as the > changes will be done non-destructively. As long as the changes are incremental and don't have to be reversed, then yeah, increasing the number in the version check should work fine. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Use real version in /apps/evolution/last_version
On Thu, 2010-12-02 at 07:43 -0600, Matthew Barnes wrote: > Seems fine to me, as long as we continue to target the last stable > version as the source to migrate from. Does it mean that the migration routines should be clever enough to know whether they were running already, though the version will indicate they didn't? I would use the last version in the migration code check, and if any fix in the migration routine would be done after another release, then just increase the number in the version check. It might work as long as the changes will be done non-destructively. On the other hand, if you think the little breakage is acceptable in development releases, then this might not worth the trouble. Maybe. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Use real version in /apps/evolution/last_version
On Thu, 2010-12-02 at 14:16 +0100, Milan Crha wrote: > just a question, what about using real versions in GConf key > /apps/evolution/last_version > ? There is stored 2.92.0 for the master right now, but the version in > Help->About is 2.91.4. I believe it would be better to use the real > version, the one from Help->About, also because of migration code, which > then would be usable for users using development versions as well. > > Any objections here? If not, then I will just change it, but I would > like to know whether I didn't overlook anything what may cause more > trouble than gain here. Seems fine to me, as long as we continue to target the last stable version as the source to migrate from. I just don't want to get into a situation where we have to write migration routines from, say, 2.91.4 to 2.91.5 and then 2.91.5 to 2.91.6 and then 2.91.6 to 2.91.90 just because we changed our minds about something during a single development cycle. A little bit of breakage between development releases is acceptable as long as the upgrade path from 2.32 to 3.0 is clean. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
