Write last Gogs version with compatible db version

[strk]

And include db version info

\cc @lunny, @bkcsoft, @tboerger

[tboerger]

The version of the database ist fixed with the gogs version. Nobody will really know what this database version means.

[strk]

@tboerger whoever wants to know if an upgrade will work can check the version.version table in their database, if not greater than the given number (15) then the upgrade will be smooth. Isn't that all ?

[bkcsoft]

I'm with @tboerger here, in most cases db-version will just confuse rather than help.

[strk]

On Thu, Mar 30, 2017 at 05:51:16AM -0700, bkcsoft wrote: I'm with @tboerger here, in most cases db-version will just confuse rather than help.

Whenever someone wants to upgrade from Gogs I find myself asking exactly that question: what version is your Gogs DB ? Can you see a better way to tell if an upgrade can be performed ?

[ptman]

I think documenting both gogs version and db schema version is ideal

[strk]

@lunny also please L-G-T-M if you agree with this (and what do you think about this @geek1011 ?)

[tboerger]

It's quite simple. Which version has your Gogs? It's bigger than the mentioned version? Than it's up to you to try it, it's pretty sure that there are diffs. The migration number anyway only changes with new migrations, the database will be anyway on a different state if unknwon adds a new column anywhere

[strk]

@tboerger you mean adding columns does not require a migration ? In that case I don't know if the version referenced by this PR is really the same as the current version in tables composition.

[strk]

@lunny so your vote for this is no ? I don't like pending PRs...
@ptman unfortunately only maintainers votes count here (please become one!).
@geek1011 your opinion ? @appleboy ?

[appleboy]

LGTM

[tboerger]

@strk migrations are only used to change data or to drop columns. Sync2 is always called to create new columns automatically and it doesn't change the migration number

[pgaskin]

LGTM