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

Reply via email to