Missing release/pre-release for upcoming MLS 3.7

[beutlich]

There is no release or pre-release candidate of upcoming MLS 3.7 that I can vote on. See https://github.com/modelica/ModelicaSpecification/releases.

[henrikt-ma]

I suppose the actions we need to take asap are:

• Merge master into maint/3.7 (so that we get the most up-to date presentation of the main changes).
• Tag maint/3.7 as v3.7-beta.1.
• Draft a new release based on the tag v3.7-beta.1 at https://github.com/modelica/ModelicaSpecification/releases.

Does that sound right?

[henrikt-ma]

Once we are done, we should update https://github.com/modelica/ModelicaSpecification/blob/master/RationaleMCP/DevelopmentProcess.md with a more detailed protocol to follow when making a new release.

Even better: Let RationaleMCP/DevelopmentProcess.md concentrate on the MCP development process, and move the protocol for making a new release into a separate document outside the RationaleMCP directory.

[HansOlsson]

I suppose the actions we need to take asap are:

• Merge master into maint/3.7 (so that we get the most up-to date presentation of the main changes).
• Tag maint/3.7 as v3.7-beta.1.
• Draft a new release based on the tag v3.7-beta.1 at https://github.com/modelica/ModelicaSpecification/releases.

Does that sound right?

Almost, but I would propose to simplify it by tagging it as "v3.7", but as "pre-release" and stating that it is the specification being voted on.

So:

1. Merge the updated change list into 3.7 branch. Update list of changes for 3.7 release. #3903
2. Tag it as "v3.7" but as "pre-release" and note the status in the tag/release.
3. Update the status in the tag/release based on votes (in language group and Modelica Association).

And list this as the process.

(An alternative would be to just tag it and state that the list of changes is external, but I can understand the issues.)

The reason as far as I understand:

• Only release, but instead update release-information and kind of release:
  • Having beta-releases and release candidates listed as releases will not help users after the release is final.
  • The release process means that we make a release (candidate) and then vote on it twice. It doesn't make sense to me to update the documents we are voting on during that time, as that introduces potential issues. (And similarly for packaging them as a new release, as there's the potential that there were a change).
• Note it's a release candidate, not a beta-version.
• The process does not have a formal requirement for tagging etc, as far as I can see.
• People use specification.modelica.org to look at the release, not GitHub. The 3.6 specification was marked as "pre-release" (so 3.5 was latest) until I began writing this reply, and no-one noticed and/or complained.

Updated: Added PR for the first step.

[henrikt-ma]

I don't like tags that move around, so I find it very strange to tag something as v3.7 before it has been decided that this is what will be released. I don't see any conflicting interpretation of beta in this context, but sure, we could also call it v3.7-rc.1.

I also noticed the situation for 3.6, and in my opinion that is a mess we shouldn't repeat.

[HansOlsson]

We'll discuss it at the next meeting, including the details of the work-flow.

The simplified work-flow is intended to have:

Gate	Week	Action
Announce	-2	Mail
Ready	-1	Update version in document, tag release as "pre-release" stating "to be voted on"
Start Vote Lang	0	Nothing
End Vote Lang	1	Update tag-text
Start Vote MA	2	Nothing
End Vote MA	3	Update tag-text, mark as normal release

To me there are some concerns to balance:

• The needed effort for these book-keeping changes (time and coordination).
• The risk for accidental errors (i.e., getting a different specification compared to what we voted on).
• The clarity it brings (here the tag and text are in sync, and the date isn't changed during the process, but the downside is that document itself doesn't indicate its status).

Regarding the risk for accidental errors: I note that even if master is merged into maint/3.7 and they are the same, GitHub seems to believe that a pull-request from maint/3.7 to master would generate new changes? (But, it was even messier before moving to GitHub, and it could be that I should have merged differently.)

It also depends on the available tooling in GitHub; e.g., there's "compare" for releases that makes it easy to see the changes (in the source - not in the generated documents).

A variant (of any work-flow) would be to consider the list of changes in master authoritative instead of in the branch; in that case that list of changes could be updated even after the release has started (and #3903 would not have been needed). Regardless, having the list of changes outside the specification is clearly good. We may also create a list of changes for previous releases using the same pattern - instead of forcing users to rely on the 3.6 document for older changes.