Different directory structure between branches

[tbeu]

Branch release has different directory structure (with top level directory Modelica_DeviceDrivers 1.2) than branches master or dllwrapper. This is not compatible when switching branches.

I propose to also add this top level directory (available with release branch) to other branches.

[bernhard-thiele]

Yes, I know. It's done this way because it seems to be more practical to have a directly usable Modelica library if cloning the master into a Modelica path directory (no need to copy around "Modelica_DeviceDrivers 1.2" first in order that the library is automatically loaded correctly). The release branch on the other hand is in a form that is compatible with the way Modelica libraries are automatically fetched from Github at (https://www.modelica.org/libraries).

This is not perfect, but it is a compromise that works good enough for me, so that I don't want to change it in the moment, until I'm convinced that some other procedure is more practical.

By the way, my procedure to cut a release version from the master is described here:
(https://github.com/modelica/Modelica_DeviceDrivers/wiki/How-to-create-a-new-release-version)

[tbeu]

Actually I do not like the branch management of MDD. In my fork I did a lot of commits on the release branch that are unmergeable in the end.
What I propose is:

1. Branches master and dllwrapper have same dir structure as release has now.
2. Branch release is not needed at all and can be deleted.
3. Incubate and other (inmature) features go to separate branches for dev and test like dllwrapper is now.
4. Build release versions from master branch and tag them.

Please consider this changes. Your DLR colleagues do it the same way, e.g. in PySimulator or FaultTriggering.

[tbeu]

Are you going to consider this and release a new version of MDD soon? Thank you!

[bernhard-thiele]

Sorry, I'm currently most of the time in bed with fever.I'll come back to this, if I'm better.

[tbeu]

Get well soon!

[bernhard-thiele]

Just got a new release version ready. Couldn't do any additional testing, since I'm now not at DLR anymore and thus don't have access to the DLR infrastructure.
But we have tested quiet a lot before, so that I hope the release is working as it should...

[tbeu]

After leaving DLR is your mail address given in the Readme.md still valid?

[bernhard-thiele]

No its not valid anymore. Changed it. Thanks for pointing that out.

[tbeu]

Why do the master and release branch still have different directory structure which makes switching branches almost impossible since I then need to adapt my MODELICAPATH?

[tbeu]

I do not see this fixed but am not able to reopen issue. See e.g. IdealizedContact where there is master and release branch with identical directory structure.

[tbeu]

Can you please reopen as long as it is not fixed.

[bernhard-thiele]

I was just looking into this again and would be interested in your opinion in how to do it best. Below, I considered two variants, but maybe there are good variants that I didn't think of. I think you (or somebody else) once proposed me an additional solution, but I don't find it any more.

It's important to me that the branch organisation still allows that the library can be conveniently downloaded from https://www.modelica.org/libraries (hence, that the script that automates that process still works, or alternatively, can be adapted to work with the new structure).

Variant 1

If I interpret your proposal in #17 (comment) correct, the master branch would have a directory Modelica_DeviceDrivers 1.3, just as currently the release branch.

Pros:

• This would allow easy switching and merging

Cons:

• A bit unconventional to have a version number in the development branch
• New release would require to rename directory at some point, e.g., to Modelica_DeviceDrivers 1.4

Variant 2

Do it similar to projects like IdealizedContact. Hence, the master branch would have a directory Modelica_DeviceDrivers while the release branch would have a directory Modelica_DeviceDrivers 1.3.

Pros:

• The structure of development and master branch would be more similiar than currently
• This organization seems to be quite popular for other Modelica repos

Cons:

• I suppose switching and merging would still be painful since the directory structure is not identical (but maybe I'm wrong?)

[tbeu]

I invite git expert @dietmarw to contribute in this discussion.
I guess your variant 2, i.e. naming the library folder between master and release branch like FaultTriggering or IdealizedContact would be the proposed way. There should be some indication that the release branches are read-only branches, right?

[dietmarw]

I think here is a general misunderstanding on how to use the release branch. It is not a branch to commit to other than making a cut of a new release. So it is not a branch that is supposed to be mergeable. So if you have changes to some released version that you want to merge back...you need to commit those changes in the development branch. Where this is depends on how the developers organise their repo. E.g., have a master and a vX.Y.Z-maintenance branch. The master and maintenance branches would have the same dir structure. But not the release since its sole purpose is to provide a downloadable structure.

That's at least how things are organised now. One could of course argue (and I have played wit that thought) to use the release assets for the version dependent directory structure. But up to now this is not the way the modelica.org/libraries page is build.

[dietmarw]

And to answer @tbeu's question: release-branches are basically meant read-only.

[bernhard-thiele]

Thanks @dietmarw for contributing to the discussion. I changed the directory structure in the spirit of Variant 2. If this works for @tbeu I would close the issue, but I'm also open to try different ideas.

Still, it would be nice to find a solution that allows to easily switch and merge between release and master. I think that this has benefits for maintainability, in particular for providing bugfixes for releases.

[dietmarw]

Well you can still have that just don't use release branch for any development work. Make a maintenance branch and cut releases from that one. Just treat the release branch as a special well release branch and nothing else.

[bernhard-thiele]

Hm. Yes, that could be done. What do you think @tbeu , should I add such a maintenance branch? By the way, if you think that it would be easier for you to have direct write access to the repository, this would be fine for me, too.

Regarding Modelica library development I think it would be even a bit faster to get a bugfix release if master and release branch would be coupled more closely since making a new release would be possible by just merging bugfixes from the master to the release and add a new tag to the release branch (so some steps for cutting a release which are required today could be omitted). However, it goes without saying that the process as it is today is pretty good and maybe it is already the best compromise.

[tbeu]

I think it is OK now. I would not ask for general maintenance branch. But maybe you want to move the Incubate blocks to a new branch.

[tbeu]

@bernhard-thiele Thanky you for offering push rights to MDD. If it makes life easier for you I can accept them Otherwise it is still fine for me if you double-check and select my commits before merging. Thus it is up to you.

[tbeu]

I'll close this one.