mbeddr / mps-gradle-plugin

Miscellaneous tasks that were found useful when building MPS-based projects with Gradle.
Other
14 stars 15 forks source link

update MPS version to 2020.3.6 #120

Closed jonaskraemer closed 2 years ago

jonaskraemer commented 2 years ago

since apparently master is still on 2020.3 the version update can just be merged to master, right?

arimer commented 2 years ago

@jonaskraemer - Tbh. I can't fully follow and dont understand the branching/versioning strategy of this repo. Could you please sync with @wsafonov and his work on this branch: https://github.com/mbeddr/mps-gradle-plugin/tree/mps20211 and try to figure out what the purpose of our master/main branch is?

coolya commented 2 years ago

master maintains the gradle frontend. The code that runs inside your gradle script. Hence adds new features that you can use directly from your build file which are MPS independent. This code has no dependency to MPS at all.

The mps* branches maintain the mps "backends" which is the code that runs in a different JVM and directly interacts with MPS classes.

While mps updates on master don't harm it's much more important to get the changes into the mps specific branches.

Frontend and backend communicate via a command line interface which is pretty stable. If the command line interface is changed in an incompatible way there is a version number that has be get incremented. e.g. here

https://github.com/mbeddr/mps-gradle-plugin/blob/master/modelcheck/build.gradle.kts#L30

jonaskraemer commented 2 years ago

@coolya thank you, that info helps a lot. So putting the version change to 2020.3.6 on mps20203 was correct, we don't need this PR at all, and in order to publish a version of the plugins for MPS 2020.3.6 to github packages we simply need to bring the publication changes from master over to mps20203 as well - did I understand that correctly?

Or is there anything I'm missing here - can we break something by adding the github packages publication to mps20203?

sergej-koscejev commented 2 years ago

JFTR I think if we want to support multiple MPS versions with one version of the plugin then we ought to put all the different MPS- version-specific variations of code in subdirectories rather than in branches. This is a side remark that shouldn't block this PR from getting merged.

coolya commented 2 years ago

@jonaskraemer feel free to merge the publication changes into the branch.

coolya commented 2 years ago

@sergej-koscejev I totally agree. Right now the only MPS version specific change was the plugin path changes for 2020.1 but these should be backwards compatible anyway. The biggest pain point is the jackson dependency. MPS/Idea ships its own version but does not include the kotlin extension for it. At least not until 2020.3. I haven't checked newer versions.

Since we are using the kotlin extensions the version need to match otherwise we end up with all kind of weird errors at runtime because of missing methods and fields. AFAIK this is the only reason why we have mps specific publications at the moment.

jonaskraemer commented 2 years ago

This change is not required on master. Instead I put the ghp publication from master onto the 20203 branch.