Pulp_deb and semver

Development
#1

The pulpcore docs more or less state that: “Pulp uses […] Semantic Versioning”

My question is if this promise is meant to apply only to pulpcore or to all of Pulp (including plugins)?

Whatever the intention, I can say that (rightly or wrongly) pulp_deb has not and does not adhere to all of the standard semver rules. I don’t particularly want to adhear to semver for pulp_deb, so if that promise is meant to apply to all plugins, I am in need of some convincing.

If that promise is not meant to apply to all plugins, we should make this explicit in the pulpcore documentation, since as currently stated, most users probably read it as applying to plugins as well.

2 Likes
#2

Why not just increment the X version of the plugin when you are making backwards incompatible changes?

#3

I could do that, but there are also other things where I am actively considering departing from semver. For example I am thinking of allowing some types of feature backports to the latest Y-branches, in order to minimize the number of release branches that need to be maintained. There are also bits of the pulp_deb API that have never received much attention, so once we get to those, every other Y release might end up being a Z release. Also, just because something is a Z release, does not mean the Y release before it would be maintained longer. So I am not sure that wouldn’t create other unmet expectations for users. I still feel conflicted about “just use semver for pulp_deb”.

In the past the main reason I did not adhere to semver was that I simply did not have this topic on my radar, so I am hoping to arrive at a deliberate choice one way or the other now.

#4

For example I am thinking of allowing some types of feature backports to the latest Y-branches

Isn’t that a bit dangerous? I’m new to backporting world, but I think that the users that choose to pin a Y version are the ones who should take the risk of upgrading it, if they think it’s worth. Maybe if there is a note on the docs/release-announcements about the current state of things (Y being frequently but low-risk, if I understand correctly) they can make well-informed decisions.

Also, using the supported_release_branches (on plugin template config) isn’t enough for not committing to maintain too many Y release branches? The notes on announcements/changelog may help to say something like:

  • "hey, this Y release is probably not going to be long term maintained because of (...)" or
  • "hey, this one is a good candidate for pinning because of (...) ".

There are also bits of the pulp_deb API that have never received much attention, so once we get to those, every other Y release might end up being a Z release.

When that happens, would it be more comfortable to stick to semver?

#5

One note: A feature (or even a bugfix) that requires a migration collides Very Badly with selective-backporting, because of the way django-migrations work.

Now, on to my OpEd:

My personal opinion is, semver is very useful for “humans who use our software”. Pretty much every argument I have seen opposed to it falls into one of two camps : “it’s a pain to maintain multiple versions”, and “we shouldn’t use it at all because sometimes we slip up and violate one of the guidelines”. Both of these seem, in my opinion, to put developer-priorities ahead of user-priorities.

I think that’s backwards. No matter how cool the code we write feels - it exists so that people out there “in the world” can get their real jobs done. Taking on the inconvenience, and the discipline, so our users don’t have to, is literally what we get paid for.

Anyway - all of the above is my personal opinion, and in no way intended to be anything like Absolute Rules. But, you did ask :slight_smile:

#6

I think Grant sums up my experience as a user. Having all plugins use semver is very beneficial for users for two reasons. First it means that versioning is consistent across plugins (e.g. I don’t have to guess how a plugin might be versioning their releases) and also, semver is widely used and well understood.

That said, I am cognizant of the fact that for a plugin developer it can be difficult to abide by semver. I wonder if there are some solutions like using the tech preview label (which pulpcore and other plugins use) or declaring that some portions of the API aren’t covered by semver?