Hello again, > We have been trying to maintain a linear history with git following the > process explained in the README.developers file. I think that the fork and > pull-request system would break this?
Not necessarily, you can ask people submitting a PR that they rebase against master. You can even enforce as a required check before merging that new branches are up to date with the latest changes in master. In the scenario I am suggesting, you would just end up with a new branch that starts at a tag and will contain bug fixes only. It will never need to be merged into master as it will consist of commits that were cherrypicked from master. This kind of workflow is used for example by all GNOME projects such as glib and gtk+: development occurs on master, when a new major release is ready, a tag is created (e.g. 3.22.0), as well as a new branch with the name of that major release (gtk-3-22), which will then receive bug fixes that were cherrypicked from master, but not its new features! Every now and then maintenance releases will be created off this branch like 3.22.1, 3.22.2 etc. > I am not familiar with Travis-CI or AppVeyor but they sound interesting. Nowadays Continuous Integration is a standard tool for automated testing and building nightly releases. With Travis-CI and AppVeyor you can easily configure that each commit sets of a number of builds on Linux, Mac OS X and Windows using any combination of options and compilers you want. Plus it’s completely free for open-source projects! It is also possible to require PRs to successfully build and survive testing on Travis-CI and AppVeyor as a precondition for being merged in. For an example of Travis-CI and AppVeyor, have a look at for example https://github.com/tschoonj/easyRNG <https://github.com/tschoonj/easyRNG>, scroll to the end of the page and click on the green badges. Best, Tom > On 22 Sep 2016, at 13:29, Hazen Babcock <hbabc...@mac.com> wrote: > > On 09/22/2016 04:58 AM, Tom Schoonjans wrote: >> >> Thanks for the fast reply. >> >> I appreciate that you want to make sure that all newly implemented features >> have been properly tested before making the next release. Surely we can all >> benefit from that. >> >> However, since a new release is at least a month from now, I still would >> like to urge you to release a maintenance release (5.11.2) in the meantime, >> which branches off the commit tagged as ‘plplot-5.11.1’ and cherrypicks the >> two commits (and possibly other bugfixes) from master to ensure it builds >> properly with CMake 3.6. >> >> On a side note, I am also wondering if it would be possible to set up a >> mirror of the repository on GitHub? The fork and pull-request system is >> extremely good for collaboration. Also, it would be trivial to implement >> continuous integration support with e.g. Travis-CI and AppVeyor, which >> should really make testing a lot easier. I would gladly help out with that. >> >> Best regards, >> >> Tom > > We have been trying to maintain a linear history with git following the > process explained in the README.developers file. I think that the fork and > pull-request system would break this? > > Also, I have been maintaining an unofficial mirror here: > https://github.com/HazenBabcock/PLplot > > And we do have a PLplot organization on github, though we've not done much > with it: > https://github.com/PLplot > > I am not familiar with Travis-CI or AppVeyor but they sound interesting. > > best, > -Hazen >
------------------------------------------------------------------------------
_______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
