From: William S F. <ws...@fu...> - 2017-02-13 20:01:58
|
The more branched development model is something we ought to consider. It's pretty much what I want to do over the next few months (master and next branches). Previously I've steered away from this model as it takes extra resources to maintain two branches which we don't have. Certainly when we were using Subversion, but now in hindsight with the move to github and Travis, it should be a lot easier to maintain two branches. With two branches, it would certainly be easier to accept more risky changes and pay proper attention to the next version. This would solve the reservations I've had for merging risky core changes such as the doxygen improvements into the stable releases. William On 11 February 2017 at 12:51, William S Fulton <ws...@fu...> wrote: > +swig-devel list > > ---------- Forwarded message ---------- > From: <mik...@co...> > Date: 10 February 2017 at 20:38 > Subject: [Swig-devel] Radical new approach to development and moving > towards version 3.1 or version 4.0 > To: William S Fulton <ws...@fu...> > > > >>>>> " " == William S Fulton <ws...@fu...> writes: > > [...] > > > To this end, I propose any sub-standard module will require an > > additional SWIG flag to make this clear. Something like: > > -sub-standard-module-which-can-only-be-used-if-I-help-fix-problems. > > My suggestion would be '-experimental'. So a feature/language would > be either experimental or not experimental (standard, regular, fully > supported, etc). > > [...] > > > I would like to start the 3.1 branch by merging in the doxygen > > branch. Vadim, any reason not to do this now? Going forwards, > > I'll merge master regularly to the 3.1 branch and suggest we > > have Travis testing on both master and the 3.1 branch. Unless > > there is a lot of developer participation on the 3.1 branch, I > > expect it will take a few months to get ready in which case we > > may need another one or two 3.0.x releases. > > My two cents (and worth no more than that) is that switching to a > more branched development model would be a major improvement to swig > development. At any one point in time there would be exactly two > active branches to check in code to. They would be either the next > "major" release (3.X) or the current bug fix release (3.(X-1).y). > > Only bug fixes that are very low risk would go into the 3.(X-1).y > branch. And nothing that even hints and possible backwards > incompatibility would be allowed there. The supported versions of > target languages (python, tcl, perl, etc) could be "locked" for this > branch. > > Having a second 3.X branch always around would be a much needed > improvement to swig's development model (as I see it). There would > now be a place for developers to work on new features of target > languages as they evolve. This branch can break backwards > compatibility. Can add new target languages and features. Supported > versions of target languages can change. > > Many other projects use such an approach. I think it might make > sense for swig to use one as well. Rather than re-inventing the > wheel, it might be possible to look at how some other projects manage > multiple active branches and adopt one of their methodologies. > > Mike > > > > |