On Tue, Sep 2, 2014 at 10:48 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > > On 02-Sep-2014, at 4:38 pm, David Nalley <da...@gnsa.us> wrote: >> I agree - how will users upgrade from 4.3.1 to 4.4.x or later - schema >> changes aren't necessarily going to screw up the upgrade process, but >> certainly have a high likelihood of doing so. What happens when >> 4.3.0-to-4.4.0.sql runs? The table already exists - and upgrade will >> puke. 4.4.0 is already released; so not like you can roll that change >> back. > > Since 4.4.0 is already released, people who will install 4.3.1 won’t be able > to upgrade to 4.4.0 as the 4.4.0 artifacts won’t have an upgrade path from > 4.3.1 to 4.4.0; but this can be only fixed (i.e. have an upgrade path) in > 4.4.1. >
Yes, I understand that, but think about all of the changes in 4.4.0 - those changes (including the duplicated ones you're proposing) still have to run against the database - e.g. - the database has to go through the cycles to make it to 4.4.0, even if it is but an interim step. Unless you are talking about obviating the need to run the 4.4.0 schema changes entirely - and that also scares me. That's new upgrade path from 4.4.1, while we think we have a decent upgrade path at present. > For 4.3.1, we can still have the changes but 4.3.1 users would only be able > to upgrade to 4.4.1 or later releases and not 4.4.0 because there is no path > from 4.3.1 to 4.4.0 in 4.4.0 release. > Think in database releases rather than code release - you can't get to 4.4.1 without traversing 4.4.0 - there are other changes; unless you are talking rebuilding the database upgrade portion entirely....and skipping 4.4.0. > This is true for all ACS releases, only the latest releases know and have > upgrade paths. So, what I also proposed here was to refactor the whole > upgrade logic as a tool and maintain it separately and this tool can perhaps > has its own release process that is faster than the ACS releases and this > tool knows about all the releases and has the necessary upgrade paths. > Honestly the db upgrade process does concern me - others have mentioned tools like flyway and I like the idea - esp if we do database design in such a way that we can downgrade as well as upgrade. I would love to see a proposal on doing this better, though I don't think it would solve this particular problem.
