Configuration management
Locked
 
|
Hi all,
I am afraid that I do not know how to put this in a smaller mail, as I believe a bit of historical background and theoretical background is in needed. But maybe I should split this in 2 mails. First the background. You can skip this mail, if you believe you know all this. Before we used git, there was a lot of discussion how to to proper software configuration management for our open source projects. One of the major problems was that a new version of a package was usually a development versions, and might break the build and also other projects. Metacello allowed us to solve this problem. As Dale always has pointed out, not all projects are the same, so there is not one solutions fits all. This was reflected in Metacello, that supported most (if not all) of these strategies. But just as we agreed on using MIT for our licensing the open source projects, in the end there was agreement on how to do make configurations. There were baselines, that described what packages were used and where these packages could be found - no version information was included here, only the dependencies There were concrete versions, that described what versions of packages belonged together - all versions where explicit, also the versions of the projects used.These versions were frozen. We defined symbolic versions, that described on a meta level the versions (releases and stable version) - these versions where aliases to a concrete version, that could change over time, to include bug fixes. By moving our projects to GIT we could use the version management of GIT, and needed less of Metacello. In GIT we have good branch support, something that lacked in Metacallo. Using git means, it is no longer necessary to define versions in Metacello. Each concrete or symbolic version can be indicated by either tag, or a branch. There is one special branch “master” that is implicitly the stable version. This is supported by git tools, i.e. before merging a pull request in a branch, one can build this pull request, verifying that it s indeed a stable version, and when this was in error, it is easy to revert the change, but leaving this change available for further development. For long term support of releases, one can create a branch (preferable recognisable by calling it isomething like masterv2.3 or release2.3), and merge bug fixes into this branch when applicable. Also in GIT it is possible for each user to fork a project at a certain version, allowing everyone to freeze a certain project to a certain version, and still be able to get updates on changes, and giving the option to easily merge this change or bug fix into their fork, or leave this change out. Finally there is a method to refer to a specific version in GitHub by including to the tag/branch name in the url: <git-url>//<projectname>[:<branchname>]/<source-dir>. This branch name is optional, and when left out, it automatically refers to master. Regards, Diego _______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
|
|
Hi all,
Here is my second part, also a reply to: “broken build" We currently have a problem in Seaside-Magritte, because Magritte refers to a specific version of Seaside and Grease, but Seaside refers to the master of Grease, which results in a mismatch of versions. Of course, you can ignore this in your load, but I do not think this should be the solution. The rationale of Seaside is the following: > On 17 May 2019, at 07:56, Johan Brichau <[hidden email]> wrote: > > For Seaside, we don’t do long-term support for any particular version, so we went with one master branch. Versions are tags. > > Seaside references other projects at their master HEAD because it assumes the latest version is best for each platform and is compatible. For Grease, we maintain backwards compatibility ourselves. > If all projects would apply semantic versioning (like in the npm package universe), it would be easier to reference major versions. This, of course, means that if you want to load an older version that it’s up to you to check which versions of the dependencies were applicable at that time. For example, if we break Grease backwards compatibility, it will be hard to load Seaside 3.1 because it references latest Grease. But at this time, it is actually the inverse: if you want to use Seaside 3.1 on latest Pharo 7, you would at least need to load latest Grease because the previous versions are incompatible with Pharo 7. That seems like a good strategy to me, but requires that all projects using Seaside and Grease refer to the master of Grease, as Seaside does so as well. If we do want long-term support of a project for older versions, we can create a branch with a specific version, and in this version we can refer to specific versions of other projects. For Magritte the original strategy was followed, ensuring that the referred projects (Seaside and Grease) are referenced by a concrete version (in the baseline). Changing this to master is a big change, and should not be done just because Seaside-Magritte does not load in Pharo7. I first proposed to a few people that in our open source projects the master should refer to the master. Both Cyril and Dale responded that they preferred to reference a major release, so bug fixes are included without manual work but that you do not get any interface breaking changes. Either way would solve the broken build of Magritte-Seaside, but mixing them like we do now is not a good idea (like driving right or driving left). So my question is: - should we ask the Seaside people to create a release branch, OR: - do we refer to master in the master of Magritte. regards, Diego > On 19 May 2019, at 16:39, Diego Lont <[hidden email]> wrote: > > Hi all, > > I am afraid that I do not know how to put this in a smaller mail, as I believe a bit of historical background and theoretical background is in needed. But maybe I should split this in 2 mails. First the background. You can skip this mail, if you believe you know all this. > > Before we used git, there was a lot of discussion how to to proper software configuration management for our open source projects. One of the major problems was that a new version of a package was usually a development versions, and might break the build and also other projects. Metacello allowed us to solve this problem. As Dale always has pointed out, not all projects are the same, so there is not one solutions fits all. This was reflected in Metacello, that supported most (if not all) of these strategies. But just as we agreed on using MIT for our licensing the open source projects, in the end there was agreement on how to do make configurations. > > There were baselines, that described what packages were used and where these packages could be found > - no version information was included here, only the dependencies > There were concrete versions, that described what versions of packages belonged together > - all versions where explicit, also the versions of the projects used.These versions were frozen. > We defined symbolic versions, that described on a meta level the versions (releases and stable version) > - these versions where aliases to a concrete version, that could change over time, to include bug fixes. > > By moving our projects to GIT we could use the version management of GIT, and needed less of Metacello. > > In GIT we have good branch support, something that lacked in Metacallo. Using git means, it is no longer necessary to define versions in Metacello. Each concrete or symbolic version can be indicated by either tag, or a branch. > > There is one special branch “master” that is implicitly the stable version. This is supported by git tools, i.e. before merging a pull request in a branch, one can build this pull request, verifying that it s indeed a stable version, and when this was in error, it is easy to revert the change, but leaving this change available for further development. > > For long term support of releases, one can create a branch (preferable recognisable by calling it isomething like masterv2.3 or release2.3), and merge bug fixes into this branch when applicable. > > Also in GIT it is possible for each user to fork a project at a certain version, allowing everyone to freeze a certain project to a certain version, and still be able to get updates on changes, and giving the option to easily merge this change or bug fix into their fork, or leave this change out. > > Finally there is a method to refer to a specific version in GitHub by including to the tag/branch name in the url: <git-url>//<projectname>[:<branchname>]/<source-dir>. This branch name is optional, and when left out, it automatically refers to master. > > Regards, > Diego > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.list.inf.unibe.ch/listinfo/smallwiki _______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
|
|
Third option: - use semantic versioning tags (e.g. v1.4.x). It keeps the option open to branch an older version for LTS and move the tag. I just added them for Seaside and Grease. I need to adjust the baseline of Seaside to reference the semantic version tag. Johan _______________________________________________ Magritte, Pier and Related Tools ... https://www.list.inf.unibe.ch/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |