Just a thought, but perhaps we should start by considering how the evolution of the product should be reflected in the versioning.
Are we committed to semantic versioning? For API, semantic versioning generally has very specific set of conventions. However, in my experience, for a software product, the relationship between features and version numbers is much less clear cut. What kinds of new features should constitute a major or minor version increment? Many products have skirted this question by dropping the semantic versioning in favor of some sort of version scheme based on a time-boxed release cycle. Would something like that be more appropriate here? What would that mean with respect to versioning for the API that Guacamole exposes for extensions and such? Again, just trying to stimulate some discussion here. carl > On Jan 11, 2019, at 5:16 AM, Nick Couchman <vn...@apache.org> wrote: > > At the risk of raining on the parade of having just released one of the > biggest sets of changes in Guacamole's history, I'd like to kick off the > discussion on where we go from here. > > We have our new versioning scheme, inaugurated here in the 1.0.0 release, > which should allow us to release more often and provide incremental bug > fixes and feature releases. However, we already have several changes in > the git master branch that represent another major release - 2.0.0. > Furthermore, as you'd expect with any major release like 1.0.0, we've had a > few bugs pop up that probably need to be squashed quickly. So, as I see > it, we have a couple of options... > > 1) Work toward a 2.0.0 release here in the near-future (weeks?), with the > current list of items in JIRA plus whatever bugs come up over the next > couple of weeks. According to JIRA we already have 32 issues tagged for > 2.0.0 - 27 of them completed. I would imagine a handful of the recent > identified bugs could also get added to that list. From 2.0.0 we could > move toward maintaining a couple of different branches that would allow for > a little more flexibility in controlling releases. > > 2) Try to do a 1.0.1 release made up of mostly bug fixes. We'd have to > create a branch from the 1.0.0 tag and then work to merge in any of the > commits from the current master head that are deemed minor enough to > qualify for a bug fix release. We can also incorporate in some of the > issues that are popping up right now as people are finding them on the > 1.0.0 release. I'm going to guess that this will require quite a bit more > effort to accomplish - extracting out the changes from master and sort of > "back-porting" them to where the 1.0.0 code is will probably require some > massaging of the code in certain places, and I wonder if it's really worth > all of that work and how quickly we could get that done? > > Those are my two ideas - maybe there are others? I think I'm more in favor > of pushing forward with a 2.0.0 release quickly and then beginning to > maintain other branches from that point that would allow us to better > leverage our new versioning scheme. > > Anyone else have ideas/thoughts about this? I've not been actively > involved in many other software development projects, so not sure how this > is generally handled, either in Open Source projects or in the commercial > software world? > > -Nick
