New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide versioning for libmypaint: separate from MyPaint, or not? #29

Closed
achadwick opened this Issue Dec 21, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@achadwick
Member

achadwick commented Dec 21, 2015

Once libmypaint has split off from MyPaint properly (mypaint/mypaint#535), should it be given its own distinct version number, or should its version be pegged to MyPaint's version?

@Jehan

This comment has been minimized.

Show comment
Hide comment
@Jehan

Jehan Dec 22, 2015

Member

I guess it all depends if one project becomes much faster than the other. In particular if libmypaint becomes so used in third-party projects that it gets bug fixes faster than MyPaint itself is released, it may then be wised to release a version of libmypaint separately.

This said, libmypaint can start as following MyPaint's version and if the need arises some day, then you can always split later. Or you can split already now and make the separation as clean as possible.

I know: my answer is not helpful. :-P

Member

Jehan commented Dec 22, 2015

I guess it all depends if one project becomes much faster than the other. In particular if libmypaint becomes so used in third-party projects that it gets bug fixes faster than MyPaint itself is released, it may then be wised to release a version of libmypaint separately.

This said, libmypaint can start as following MyPaint's version and if the need arises some day, then you can always split later. Or you can split already now and make the separation as clean as possible.

I know: my answer is not helpful. :-P

@hartwork

This comment has been minimized.

Show comment
Hide comment
@hartwork

hartwork Dec 23, 2015

Contributor

Since Gimp is checking for libmypaint >=1.1 current, please don't start at something below like 0.8 or so. If that's out of discussion anyway, please excuse the noise.

Contributor

hartwork commented Dec 23, 2015

Since Gimp is checking for libmypaint >=1.1 current, please don't start at something below like 0.8 or so. If that's out of discussion anyway, please excuse the noise.

@odysseywestra

This comment has been minimized.

Show comment
Hide comment
@odysseywestra

odysseywestra Dec 24, 2015

Member

I would vote starting off with same version as MyPaint currently is and
keep it version number in line with MyPaint to avoid confusion.

On Wed, Dec 23, 2015, 3:10 PM Sebastian Pipping notifications@github.com
wrote:

Since Gimp is checking for libmypaint >=1.1 current, please don't start at
something below like 0.8 or so. If that's out of discussion anyway, please
excuse the noise.


Reply to this email directly or view it on GitHub
#29 (comment).

-- Albert Westra

Member

odysseywestra commented Dec 24, 2015

I would vote starting off with same version as MyPaint currently is and
keep it version number in line with MyPaint to avoid confusion.

On Wed, Dec 23, 2015, 3:10 PM Sebastian Pipping notifications@github.com
wrote:

Since Gimp is checking for libmypaint >=1.1 current, please don't start at
something below like 0.8 or so. If that's out of discussion anyway, please
excuse the noise.


Reply to this email directly or view it on GitHub
#29 (comment).

-- Albert Westra

@achadwick

This comment has been minimized.

Show comment
Hide comment
@achadwick

achadwick Dec 24, 2015

Member

@hartwork Existing/deployed .pc files matter, so we won't go before those. Currently you'll get 1.1 in those.

Noting that even huge projects like GNOME basically even peg app versions to the main version number. It can be done. Let's do as @odysseywestra suggests initially, and bump libmypaint's .pc version forward to 1.2.0 at the upcoming MyPaint release so that GIMP can be sure it's getting the latest translations at least. When libmypaint goes independent (probably at 1.2.1), we'll start bumping both together and see what happens.

Member

achadwick commented Dec 24, 2015

@hartwork Existing/deployed .pc files matter, so we won't go before those. Currently you'll get 1.1 in those.

Noting that even huge projects like GNOME basically even peg app versions to the main version number. It can be done. Let's do as @odysseywestra suggests initially, and bump libmypaint's .pc version forward to 1.2.0 at the upcoming MyPaint release so that GIMP can be sure it's getting the latest translations at least. When libmypaint goes independent (probably at 1.2.1), we'll start bumping both together and see what happens.

@Jehan

This comment has been minimized.

Show comment
Hide comment
@Jehan

Jehan Dec 24, 2015

Member

I doubt down-versioning was ever an alternative for upstream so I didn't even mention it. In case it was not, of course any split version number should continue after the current shared version.

Member

Jehan commented Dec 24, 2015

I doubt down-versioning was ever an alternative for upstream so I didn't even mention it. In case it was not, of course any split version number should continue after the current shared version.

@achadwick

This comment has been minimized.

Show comment
Hide comment
@achadwick

achadwick Feb 1, 2016

Member

Oh, drat. I didn't bump brushlib_version for the MyPaint release as I said I would. That will have to change for the first release, in that case. Anyway, time to review milestones and suchlike.

libmypaint is now sharedlib-by-default, so we could call what we have v1.2.0 since it's basically what MyPaint v1.2.0 is using. Let's create a formal v1.2.0 release tag soon.

I would like to use Semantic Versioning for libmypaint: http://semver.org/, similar to MyPaint. I am happy for the versions to start drifting right away.

Member

achadwick commented Feb 1, 2016

Oh, drat. I didn't bump brushlib_version for the MyPaint release as I said I would. That will have to change for the first release, in that case. Anyway, time to review milestones and suchlike.

libmypaint is now sharedlib-by-default, so we could call what we have v1.2.0 since it's basically what MyPaint v1.2.0 is using. Let's create a formal v1.2.0 release tag soon.

I would like to use Semantic Versioning for libmypaint: http://semver.org/, similar to MyPaint. I am happy for the versions to start drifting right away.

@achadwick achadwick self-assigned this Feb 1, 2016

@achadwick achadwick added the project label Feb 1, 2016

@achadwick achadwick added this to the v1.2.0 milestone Feb 1, 2016

@Jehan

This comment has been minimized.

Show comment
Hide comment
@Jehan

Jehan Feb 1, 2016

Member

Awesome. Speaking of drifting version, would it be possible to review mypaint/mypaint#538 which would create a data package (which could itself have its own drifting versionning)?
This would be a big deal for GIMP.

Member

Jehan commented Feb 1, 2016

Awesome. Speaking of drifting version, would it be possible to review mypaint/mypaint#538 which would create a data package (which could itself have its own drifting versionning)?
This would be a big deal for GIMP.

@achadwick

This comment has been minimized.

Show comment
Hide comment
@achadwick

achadwick May 5, 2016

Member

"Soon"... ahem, whoops. I got sidetracked by the MyPaint release and real life. Need to re-focus on this and make a decision.

I think MyPaint 1.3.0 will be the first to use the independent libmypaint, so maybe our initial independent release of libmypaint should match that version. Thinking about it again, it would be nice for us to avoid confusion while were doing the split. We can decide whether to let versions drift or keep them in step afterwards.

MyPaint has a v1.2.x branch for the 1.2.1 release and any little bugfix releases beyond that point. It uses SCons and the submodule trick, and it can remain pinned to a specific historic libmypaint revision without any trouble.

Member

achadwick commented May 5, 2016

"Soon"... ahem, whoops. I got sidetracked by the MyPaint release and real life. Need to re-focus on this and make a decision.

I think MyPaint 1.3.0 will be the first to use the independent libmypaint, so maybe our initial independent release of libmypaint should match that version. Thinking about it again, it would be nice for us to avoid confusion while were doing the split. We can decide whether to let versions drift or keep them in step afterwards.

MyPaint has a v1.2.x branch for the 1.2.1 release and any little bugfix releases beyond that point. It uses SCons and the submodule trick, and it can remain pinned to a specific historic libmypaint revision without any trouble.

@achadwick

This comment has been minimized.

Show comment
Hide comment
@achadwick

achadwick May 5, 2016

Member

Milestone renamed https://github.com/mypaint/libmypaint/milestones/v1.3.0, and we have a plan now.

Member

achadwick commented May 5, 2016

Milestone renamed https://github.com/mypaint/libmypaint/milestones/v1.3.0, and we have a plan now.

@achadwick achadwick closed this May 5, 2016

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