On 1/4/2015 05:56, Ruben Van Boxem wrote: > It would all depend on how the developers handle this, but here's an idea: > - keep master stable (even more than it is now), merging finished features > and bugfixes only. > - create a staging branch which would contain all new features whenever a > feature developer feels his work is ready enough for tessting. This would > take the place of current master, which contains everything from stable to > unstable commits. > - create true feature branches, which track either staging or master, and > develop each feature in here. Timely merges with staging will allow stuff > like upstream Fedora to keep testing the whole. When finished, a > feature-branch will merge with master, finalizing feature development. > > In this scheme, master is dead-stable, and releases are only for > distributors to have some form of "latest release". Heck, versioning could > take on a pure incremental scheme (see e.g. systemd), IMHO. I see no reason > why one would want to use an older version anyways. Most native toolchains > are based off of master currently! > The only issue I see right now with my suggestion is that staging and > master could diverge a bit, as the former contains a lot of other changes > not in master due to the different features. This will require quite some > discipline from the developers to keep each commit local to where it > belongs. But a normal staging branch which includes all changes isn't an > option, as that is the state of current master.
We've been through this, nothing will be merged into master then, since it needs to be stable. We'd end up with the exact same situation currently, with "master" requiring extensive backports from "feature", not to mention the integration pains when there are multiple "feature" branches to track with varying levels of completeness and stability. What we will do is release an alpha version of 4.0 from master for testing and bugfixes only, this way, it is still close enough to master while no longer taking on untested code.
0xD4EBC740.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
