On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper <[email protected]> wrote:
> On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman <[email protected]> wrote: > > > On Fri, Jan 11, 2019 at 8:11 AM carl harris <[email protected]> > wrote: > > ... > > > > > > 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? > > > > > > > I'm not opposed to such a versioning scheme. My only question would be > how > > to deal with the API-level changes that you mentioned before, and that > > we've currently identified for the "major release" changes? Is there a > way > > that these sort of time-boxed releases handle that in the versioning? > > > > Another option might be to provide some sort of API compatibility layer > within the webapp, allowing the extensions of prior releases to continue to > function. If compatibility doesn't break as a result of API changes, > there's no need for a full major version bump, and downstream migration for > future releases is much easier. > > I'm open to this, as well. How much effort do we think would be involved in introducing something like this? I guess, whatever methodology we choose for this going forward, I'm interested in maintaining the momentum of the really cool 1.0.0 release we just put out - I think we'll be able to increase community involvement and interest by maintaining and more frequent release cycle, which I believe the new version numbering is supposed to facilitate. It'd be nice to identify a sustainable way to develop and version going forward, and turn around another release (2.0.0, 1.0.1, 1.0-201902, etc.) quickly. Sorry if I'm coming across as push, but I'm very interested in carrying the energy and momentum forward :-). -Nick
