On Thu, Jan 17, 2019, 13:02 Nick Couchman <vn...@apache.org wrote: > On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper <mjum...@apache.org> wrote: > > > On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman <vn...@apache.org> wrote: > > > > > On Fri, Jan 11, 2019 at 8:11 AM carl harris <ceharris...@gmail.com> > > 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? >
A compat layer would be pretty tricky. If we can somehow modify the API changes such that things are inherently compatible, then fairly easy. Maybe something can be done with default methods now that we're Java 8+? > 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. > +1 > Sorry if I'm coming across as push, but I'm very interested in carrying the > energy and momentum forward :-). > I definitely agree. There's been a remarkable uptick in community involvement following 1.0.0 which we should work to encourage. - Mike
