Skip to content
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
Closed

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

achadwick opened this issue Dec 21, 2015 · 9 comments
Assignees
Labels
Milestone

Comments

@achadwick
Copy link
Member

@achadwick 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
Copy link
Member

@Jehan 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
Copy link
Contributor

@hartwork 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
Copy link
Member

@odysseywestra 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
Copy link
Member Author

@achadwick 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
Copy link
Member

@Jehan 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
Copy link
Member Author

@achadwick 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
Copy link
Member

@Jehan 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
Copy link
Member Author

@achadwick 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
Copy link
Member Author

@achadwick 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.