> * master - dev branch of the next release (currently marching towards 3.5) > * 3.4.x - dev branch for a point or security release of the 3.4.x line > once a new minor version is cut (e.g. 3.5) > * 3.3.x - dev branch for a point or security release of the 3.3.x line
That's where we landed with very loose agreement, very little experience and no documentation to drive how it works in practice. In practice no one is maintaining 3.3.x. I was intending to merge everything from master into 3.4.x since afaik there are no features inconsistent with a 3.4.12 release (i.e. nothing "earth shattering"). With current development practices, all we have to guide what goes into maint branches is the roadmap, which in practice for day-to-day commits leaves a lot of room for interpretation. The maintainer's opinion to be precise. I don't see any other solution that's ultimately not up to the perspective of some developer, but I would argue that the branch maintainer ought to be the authority on what commits are merged into a branch. > 3.4.11 was tagged on master, and at that time 3.4.x should have been > brought up to par with that tag, correct? I did that. M -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
