How do I semver a module and yet support multiple SilverStripe major releases?

38 views
Skip to first unread message

Zauberfisch

unread,
Oct 27, 2016, 4:32:18 PM10/27/16
to silverst...@googlegroups.com
Hey guys,

I raised that question on IRC yesterday and got some good input, but no
real solution. So I'd like to re-raise it here and perhaps even generate
a general recommendation for module authors:

> <Zauberfisch> hey guys
> <Zauberfisch> I need some advise on handling releases of a module
> <Zauberfisch> we always say modules should be using semver. But with ss4 in alpha now I already want to build for ss4 but still also bring releases for ss3
> <Zauberfisch> so I might end up with a major release for both ss3 and ss4.
> <Zauberfisch> But in my understanding of semver there is no good way to represent that
> [...]
> <Zauberfisch> [...] my problem is what if I make 1.x => ss3 and 2.x => ss4. What if I now want to make breaking changes to the ss3 compatible version of the module?
> <Zauberfisch> I can't release a new major version because 2.x is already for ss4
> <Zauberfisch> and making 1.x+1 the new major release for ss3 conflicts with what I understand semver should be
> [...]
> <Zauberfisch> and because ss4 has a lot of breaking changes I will most likely have to support and even work on ss3 projects for a while. so I might need to release a new version of a module for both, ss4 and ss3
> <Zauberfisch> the easiest solution I can think of is making the releases ss3.1.0.0 and ss4.1.0.0, so just prefix it with the ss version and have 4 instead of 3 numbers
> <Zauberfisch> but I am wondering how other module maintainers solve this issue
> <@madmatt> Zauberfisch: yeah semver doesn't have a way of dealing with that nicely
> <@madmatt> Until SS4 is stable, I'd suggest using master for ss4 compat, and tagged versions for SS3, but that has it's own complications
> <@madmatt> Alternatively you could have a 4 branch for SS4 compat, and use your normal process for 3.x
> <Zauberfisch> I considered that
> <Zauberfisch> but realisitcly I will release new versions of that module even after 4 is stable but still need to support 3
> <Zauberfisch> so I would really like to decide on a way now that works well later on

this becomes even more relevant when we starting having LTS releases.

So, do we have any example modules that have already solved this issue?
Does anyone have experience how other frameworks/community solve this?
Or should we just roll with ss3.1.0.0 and ss4.1.0.0?

tl;dr:
What is the recommended way of releasing modules with major releases for
multiple silverstripe major releases?

Sam Minnée

unread,
Oct 27, 2016, 4:39:58 PM10/27/16
to SilverStripe Core Development
Hi everyone,

The approach that we're taking is simply to avoid the problem – to make a decision not to release any more breaking changes for the SS3-compatible version.

If you've got a bunch of major changes that you're about to release, maybe it's worth doing a new major release for SS 3.x now, but apart from that it seems like more of a theoretical problem. Are you really going to be doing so much active dev on two copies of the module in parallel? It seems like it will double the work and I'd question whether that's worth the time.

Another approach is to work harder at not breaking APIs in your SS 3.x-compatible version. If people are on SS 3.x, it's probably because they don't want to bother dealing with broken APIs in core, and so they're unlikely to be interested in doing a major version upgrade of your module. SS 3.x support is about stability.

Finally, if you're really committing to maintaining two versions of the module in parallel, you could always release the SS4 compatible version with a new module name, too, with "replaces" meta-data in composer.json. 

Thanks,
Sam

Christopher Pitt

unread,
Oct 27, 2016, 4:43:13 PM10/27/16
to SilverStripe Core Development
you could always release the SS4 compatible version with a new module name, too, with "replaces" meta-data in composer.json. 
 
This is the approach Guzzle took, and is my personal favourite (assuming expected breaking changes for both versions).

Gregory Smirnov

unread,
Oct 28, 2016, 4:04:41 AM10/28/16
to silverst...@googlegroups.com
Hello guys,

The problem raised here is very old and will be never solved by semver.
Please read https://github.com/mojombo/semver/issues/265

According to Semver there are no problems that module versions 1.x.x and 3.x.x support SS3 and 2.x.x and 4.x.x support SS4.
Package manager will take care of dependencies.

The rule is one - bump Major with every BC change.
Any prefixes go away from Semver.

Other projects resolved that with prefixes in versions API.Major.Minor.Patch (3.1.0.0), APIvMajor.Minor.Patch (ss3v1.0.0), or with suffixes in the module name: silverstirpe/cms_ss4

//Gregory
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at https://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

Zauberfisch

unread,
Nov 15, 2016, 2:22:01 PM11/15/16
to silverst...@googlegroups.com
Hey,

Sam may be correct that it's more of an edge-case than I made it out to
be. But I still think it will happen once in a while.

Therefore I actually think what Gregory said is the most practical
solution. I'll just release 1.x for ss3 and 2.x for ss4 and then later
perhaps a 3.x for ss3 again if I need to release another one for ss3.

thanks a lot for the input guys.

Anselm Christophersen

unread,
Nov 15, 2016, 4:21:23 PM11/15/16
to silverst...@googlegroups.com
Not so much about semver, but about SS4 modules being backward compatible: To my understanding the biggest changes on an SS4 module would be namespaces - would 3.x also support that?
I’m thinking maybe a normal module that doesn’t use any SS4-specific features could be compatible with both versions?
That’d be my favorite scenario.

Zauberfisch

unread,
Nov 15, 2016, 4:59:33 PM11/15/16
to silverst...@googlegroups.com
very unlikely. Namespaces is major change which is impossible to
backport to 3.x without violating semver.

Theoretically you can use namespaces in ss3 already, so theoretically
you could create a namespaced module that works both in ss3 and ss4.
But, it has tons of issues such as template names and if you want to
support both ss versions you need to create class aliases for classes
that are namespaced in 4 but not in 3.

In the end you will end up with more work than maintaining 2 different
versions unfortunately.

(I attempted to use namespaces in mysite for a couple of projects with
ss3 and had to stop doing it because it just introduced to many issues
and needed to many workarounds)

Sam Minnée

unread,
Nov 15, 2016, 6:33:32 PM11/15/16
to silverst...@googlegroups.com
Yeah it's very unlikely that you'll have code that is compatible with both ss3 and ss4.
Sam Minnée
CEO
SilverStripe Limited
Reply all
Reply to author
Forward
0 new messages