Was anyone planning to release REST webservices 2.18.1?

The REST module’s version is set to 2.18.1-SNAPSHOT and there are two closed tickets with fixVersion=2.18.1.

However I just committed code for a new feature (RESTWS-656) so I plan to bump the module’s version to 2.19.0-SNAPSHOT to reflect this, and move the JIRA tickets currently listed as 2.18.1 to 2.19.0.

Or was someone intending to get a bugfix release out soon? (In that case I won’t move the JIRA issues.)

I think it was me who set it to 2.18.1-SNAPSHOT while releasing 2.18.0. I had no intention of releasing 2.18.1.

Should I have bumped open issues to 2.19.0 instead of 2.18.1 while releasing 2.18.0?

I think the default assumption should be that the next release will be a minor release, not a maintenance release. If someone wants to do a bugfix-only release, they can create an extra fixVersion at the time.

E.g. when you’re releasing REST 2.18.0, the next version should be 2.19.0, and you’d only create a JIRA version for 2.19.0.

The maven release plugin does not do this by default (e.g. when you release 2.18.0 it defaults to 2.18.1-SNAPSHOT), but maybe we can get around it with this flag (I haven’t checked how), or in our bamboo release plans.

Okay, sounds good.

Are you proposing maintenance branches?

We are starting to use semantic versioning for modules (e.g. the last REST release was 2.18.0, not 2.18.) Thanks to @teleivo for pushing on that in this thread. I will update that thread with my thoughts from this thread.

99% of the time there will be no maintenance release, so we will not usually be creating maintenance branches. If, after the fact, we realize that there’s a need for a maintenance release on some module version, we will create the maintenance branch at that time, based on the (old) release tag.

I think if we want to effectively marry the release process to the semantic versioning system it is best to have maintenance branches upfront. As much it is easy to create branches retrospectively when needed I feel like it is more efficient to have a well defined and simple process that will help avoid confusion in case someone new starts working on the project. If you have 2.19.0-SNAPSHOT without 2.18.x branch someone may accidentally release 2.19.0 while in fact what is needed is 2.18.1 version.

I don’t know but for me it feels right to have the branches as part of the process. They don’t cost anything anyway.

It does cost something. Someone would have to do the work to the create the branch. That’s small, but currently the module release process is that we trigger the Release To Maven stage in the project from Bamboo, and this uses mvn release:prepare release:perform to do the release. (If someone wants to update all of our build scripts to automatically create release branches, then we could make this shift. But it’s not on my priority list…)