Remove upgrade steps from unsupported versions #295

Closed
hvelarde opened this Issue Sep 24, 2013 · 6 comments

Comments

Projects
None yet
4 participants
Owner

hvelarde commented Sep 24, 2013

Clean the code up, please! Remove all code related to previous upgrade steps.

@ghost ghost assigned fulv Oct 9, 2013

fulv added a commit to fulv/collective.cover that referenced this issue Oct 9, 2013

hvelarde added a commit that referenced this issue Oct 9, 2013

Merge pull request #310 from fulv/master
Remove upgrade steps from unsupported versions (closes `#295`)

@hvelarde hvelarde closed this Oct 9, 2013

Owner

vangheem commented Nov 19, 2013

Aren't old upgrade steps required if you're upgrading from an earlier version? How else do you upgrade from say a1 to b6?

Owner

mauritsvanrees commented Nov 19, 2013

It looks like you should upgrade to a5 first and then to a6. I haven't checked if this is mentioned anywhere in the change log or other documentation.

Owner

hvelarde commented Nov 20, 2013

yes, that's clearly stated in the documentation; I don't want to maintain all that code there:

https://github.com/collective/collective.cover/blob/master/CHANGES.rst#10a6-2013-11-12

Owner

vangheem commented Nov 20, 2013

What's to maintain? Just leave it, it's for old upgrades. You could be forcing a user to run-buildout, restart all clients, run upgrade steps, multiple times when you remove old upgrade steps.

I think it's very bad practice to remove upgrades. You're pretty much asking for people to break their sites.

Additionally, not everyone will read every single release note for every add-on they use. Why hang them for it?

Owner

vangheem commented Nov 20, 2013

In all the addons I've maintained, I've never removed an old upgrade step and there was no cost to maintenance.

You really don't want to provide a scenario where everyone ends up hating this product because upgrades break it or are painful.

Owner

hvelarde commented Nov 20, 2013

I understand your point but, at the same time, we can not guarantee compatibility with previous versions all the time especially if we are almost the only ones maintaining the package. we have been very transparent announcing what is happening on every release and we want people to upgrade early to avoid issues.

in this specific case an announce was made 4 months in advance telling people that we were about to remove that code: nobody said anything, nobody asked anything. I even missed the removal for one release as it was originally expected to be done on release 1.0a5.

more people is starting to collaborate, so may be we are going to have more discussion now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment