Re: [DISCUSS] Beyond 1.0.0
On Sat, Feb 9, 2019 at 12:14 PM Nick Couchman wrote: > > > > > Definitely. > > > > Outside of the above, it looks like scope is generally settled. I'll move > > forward with the creation of 1.1.0 branches, etc.: > > > > http://guacamole.apache.org/release-procedures-part1/ > > > > Very nice. > > Do we want to create any branches for other versions - 1.1.1, 1.2.0, 2.0.0, > etc. - at this point? Or just continue to be careful about what gets > merged to master until we get past 1.1.0? > IMHO, let's hold off on creating other release branches until the time comes to make a decision about API-incompatible changes. We should do what we can to ensure that all changes are compatible, and bristle accordingly at changes which propose to break compatibility. If breaking compatibility is the only option, then I suppose it's discussion time for whether the community wants to support 1.2.x and 2.0.x branches simultaneously. - Mike
Re: [DISCUSS] Beyond 1.0.0
> > Definitely. > > Outside of the above, it looks like scope is generally settled. I'll move > forward with the creation of 1.1.0 branches, etc.: > > http://guacamole.apache.org/release-procedures-part1/ > Very nice. Do we want to create any branches for other versions - 1.1.1, 1.2.0, 2.0.0, etc. - at this point? Or just continue to be careful about what gets merged to master until we get past 1.1.0? -Nick
Re: [DISCUSS] Beyond 1.0.0
On Sat, Feb 2, 2019 at 4:11 PM Nick Couchman wrote: > ... > >> > >> Okay, sounds good. I've also added this to the 1.1.0 release in JIRA. > >> This brings us to 56 total issues, with 17 remaining to complete. > Several > >> of those are in progress and can be closed out as soon as code is > reviewed > >> and merged. > >> > >> > > I've also tacked -694 on this one - it deals with a missing package that > > results in certificate verification failure in Docker. Relative > small/easy > > to resolve. > > > > > And maybe 637?? > > https://issues.apache.org/jira/browse/GUACAMOLE-637 Definitely. Outside of the above, it looks like scope is generally settled. I'll move forward with the creation of 1.1.0 branches, etc.: http://guacamole.apache.org/release-procedures-part1/ - Mike
Re: [DISCUSS] Beyond 1.0.0
On Sat, Feb 2, 2019 at 2:49 PM Nick Couchman wrote: > > >> > So, I think we've probably had enough time to at least catch the biggest >> > bugs in 1.0.0 and get those into JIRA, and I think many of those have >> been >> > squashed. Are we good fixing 1.1.0 release at the following list of >> issues: >> > >> > https://issues.apache.org/jira/projects/GUACAMOLE/versions/12343049 >> > >> > And moving forward with the release? By this list we have 17 issues >> > needing to be finished up prior to cutting the release. There are >> several >> > PRs waiting for reviews to be finished up - any of the committers who >> can >> > jump on and do reviews, your help would be greatly appreciated! >> > >> >> +1 >> >> > Any others that we think should get added to the next version? >> > >> >> I'd suggest also including: >> >> https://issues.apache.org/jira/browse/GUACAMOLE-696 - "Apply database >> groups if authenticated user matches database user" >> >> and: >> >> https://issues.apache.org/jira/browse/GUACAMOLE-715 - "Permission >> management based on LDAP groups not working as documented" >> >> Both of which are issues encountered with the new user group support >> following release of 1.0.0. The former is a point of confusion which >> has resulted in a few threads on the mailing list, while the latter is >> a legitimate bug in the way delegated authentication is handled by the >> database auth (it still assumes there will be a corresponding database >> user). >> > > Agreed - I've added both of these to 1.1.0 in JIRA. If anyone has any > objections, don't hesitate to speak up, but it would be good to adjust > behavior and/or fix these bugs so as to avoid further confusion. > > >> >> I'd also say let's add the FreeRDP 2.0.0 support to the scope, and try >> to buckle down and get it done. It's becoming increasingly critical, >> particularly for downstream Linux distributions that wish to drop >> support for older FreeRDP releases. I think I should be able to manage >> it within February: >> >> https://issues.apache.org/jira/browse/GUACAMOLE-249 > > > Okay, sounds good. I've also added this to the 1.1.0 release in JIRA. > This brings us to 56 total issues, with 17 remaining to complete. Several > of those are in progress and can be closed out as soon as code is reviewed > and merged. > > I've also tacked -694 on this one - it deals with a missing package that results in certificate verification failure in Docker. Relative small/easy to resolve. -Nick >
Re: [DISCUSS] Beyond 1.0.0
> > > > > So, I think we've probably had enough time to at least catch the biggest > > bugs in 1.0.0 and get those into JIRA, and I think many of those have > been > > squashed. Are we good fixing 1.1.0 release at the following list of > issues: > > > > https://issues.apache.org/jira/projects/GUACAMOLE/versions/12343049 > > > > And moving forward with the release? By this list we have 17 issues > > needing to be finished up prior to cutting the release. There are > several > > PRs waiting for reviews to be finished up - any of the committers who can > > jump on and do reviews, your help would be greatly appreciated! > > > > +1 > > > Any others that we think should get added to the next version? > > > > I'd suggest also including: > > https://issues.apache.org/jira/browse/GUACAMOLE-696 - "Apply database > groups if authenticated user matches database user" > > and: > > https://issues.apache.org/jira/browse/GUACAMOLE-715 - "Permission > management based on LDAP groups not working as documented" > > Both of which are issues encountered with the new user group support > following release of 1.0.0. The former is a point of confusion which > has resulted in a few threads on the mailing list, while the latter is > a legitimate bug in the way delegated authentication is handled by the > database auth (it still assumes there will be a corresponding database > user). > Agreed - I've added both of these to 1.1.0 in JIRA. If anyone has any objections, don't hesitate to speak up, but it would be good to adjust behavior and/or fix these bugs so as to avoid further confusion. > > I'd also say let's add the FreeRDP 2.0.0 support to the scope, and try > to buckle down and get it done. It's becoming increasingly critical, > particularly for downstream Linux distributions that wish to drop > support for older FreeRDP releases. I think I should be able to manage > it within February: > > https://issues.apache.org/jira/browse/GUACAMOLE-249 Okay, sounds good. I've also added this to the 1.1.0 release in JIRA. This brings us to 56 total issues, with 17 remaining to complete. Several of those are in progress and can be closed out as soon as code is reviewed and merged. -Nick
Re: [DISCUSS] Beyond 1.0.0
On Fri, Feb 1, 2019 at 5:42 PM Nick Couchman wrote: > > On Tue, Jan 22, 2019 at 7:57 PM Nick Couchman wrote: > > > > >> I think the new versioning scheme still seems sensible, but following > >> 1.1.0 > >> I suggest we consider whether we should adopt a branching scheme like you > >> mentioned before. It would be nice to rely on being able to always produce > >> bugfix/minor releases without breaking compatibility. > > > > > > Agreed, and, until we do handle the branching scheme, we need to be > > looking really close at any commits we make to insure that we're not > > Introducing changes that will impact compatibility, or, if we do, that > > we're introducing the necessary changes to keep things > > backward-compatible. Just something for all committers to be aware of at > > this point. > > > > > >> > >> Our issues with producing a release following 1.0.0 are more with the > >> current existence of an incompatible change on master (and the upgrade > >> headache that implies for any users affected by bugs in 1.0.0), not with > >> the numbering. > > > > > > Sounds good. > > > > -Nick > > > > So, I think we've probably had enough time to at least catch the biggest > bugs in 1.0.0 and get those into JIRA, and I think many of those have been > squashed. Are we good fixing 1.1.0 release at the following list of issues: > > https://issues.apache.org/jira/projects/GUACAMOLE/versions/12343049 > > And moving forward with the release? By this list we have 17 issues > needing to be finished up prior to cutting the release. There are several > PRs waiting for reviews to be finished up - any of the committers who can > jump on and do reviews, your help would be greatly appreciated! > +1 > Any others that we think should get added to the next version? > I'd suggest also including: https://issues.apache.org/jira/browse/GUACAMOLE-696 - "Apply database groups if authenticated user matches database user" and: https://issues.apache.org/jira/browse/GUACAMOLE-715 - "Permission management based on LDAP groups not working as documented" Both of which are issues encountered with the new user group support following release of 1.0.0. The former is a point of confusion which has resulted in a few threads on the mailing list, while the latter is a legitimate bug in the way delegated authentication is handled by the database auth (it still assumes there will be a corresponding database user). I'd also say let's add the FreeRDP 2.0.0 support to the scope, and try to buckle down and get it done. It's becoming increasingly critical, particularly for downstream Linux distributions that wish to drop support for older FreeRDP releases. I think I should be able to manage it within February: https://issues.apache.org/jira/browse/GUACAMOLE-249 - Mike
Re: [DISCUSS] Beyond 1.0.0
On Tue, Jan 22, 2019 at 7:57 PM Nick Couchman wrote: > >> I think the new versioning scheme still seems sensible, but following >> 1.1.0 >> I suggest we consider whether we should adopt a branching scheme like you >> mentioned before. It would be nice to rely on being able to always produce >> bugfix/minor releases without breaking compatibility. > > > Agreed, and, until we do handle the branching scheme, we need to be > looking really close at any commits we make to insure that we're not > Introducing changes that will impact compatibility, or, if we do, that > we're introducing the necessary changes to keep things > backward-compatible. Just something for all committers to be aware of at > this point. > > >> >> Our issues with producing a release following 1.0.0 are more with the >> current existence of an incompatible change on master (and the upgrade >> headache that implies for any users affected by bugs in 1.0.0), not with >> the numbering. > > > Sounds good. > > -Nick > So, I think we've probably had enough time to at least catch the biggest bugs in 1.0.0 and get those into JIRA, and I think many of those have been squashed. Are we good fixing 1.1.0 release at the following list of issues: https://issues.apache.org/jira/projects/GUACAMOLE/versions/12343049 And moving forward with the release? By this list we have 17 issues needing to be finished up prior to cutting the release. There are several PRs waiting for reviews to be finished up - any of the committers who can jump on and do reviews, your help would be greatly appreciated! Any others that we think should get added to the next version? -Nick
Re: [DISCUSS] Beyond 1.0.0
On Tue, Jan 22, 2019 at 19:45 Mike Jumper : > > > > > > Very nice. So shall we try for a 1.1.0 release, next (soon)? Maybe > squash > > a few more bugs that have surfaced from 1.0.0? > > > > Sounds good to me. > > > > And do we want to continue this versioning scheme, or continue to toss > > around some of the other ideas we've talked about? > > > > I think the new versioning scheme still seems sensible, but following 1.1.0 > I suggest we consider whether we should adopt a branching scheme like you > mentioned before. It would be nice to rely on being able to always produce > bugfix/minor releases without breaking compatibility. Agreed, and, until we do handle the branching scheme, we need to be looking really close at any commits we make to insure that we're not Introducing changes that will impact compatibility, or, if we do, that we're introducing the necessary changes to keep things backward-compatible. Just something for all committers to be aware of at this point. > > Our issues with producing a release following 1.0.0 are more with the > current existence of an incompatible change on master (and the upgrade > headache that implies for any users affected by bugs in 1.0.0), not with > the numbering. Sounds good. -Nick
Re: [DISCUSS] Beyond 1.0.0
On Tue, Jan 22, 2019 at 4:19 PM Nick Couchman wrote: > On Tue, Jan 22, 2019 at 19:10 Mike Jumper wrote: > > > On Tue, Jan 22, 2019 at 6:50 AM Nick Couchman wrote: > > > > > Very cool. Was 524 the only change that would push us to a major > version > > > (2.0.0)? I can't remember off the top of my head if anything else > > > introduced API-relevant changes. > > > > > > > Yep. Other than the changes to Connectable, no other changes break > > extension compatibility with 1.0.0. > > > Very nice. So shall we try for a 1.1.0 release, next (soon)? Maybe squash > a few more bugs that have surfaced from 1.0.0? > Sounds good to me. > And do we want to continue this versioning scheme, or continue to toss > around some of the other ideas we've talked about? > I think the new versioning scheme still seems sensible, but following 1.1.0 I suggest we consider whether we should adopt a branching scheme like you mentioned before. It would be nice to rely on being able to always produce bugfix/minor releases without breaking compatibility. Our issues with producing a release following 1.0.0 are more with the current existence of an incompatible change on master (and the upgrade headache that implies for any users affected by bugs in 1.0.0), not with the numbering. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Tue, Jan 22, 2019 at 19:10 Mike Jumper wrote: > On Tue, Jan 22, 2019 at 6:50 AM Nick Couchman wrote: > > > Very cool. Was 524 the only change that would push us to a major version > > (2.0.0)? I can't remember off the top of my head if anything else > > introduced API-relevant changes. > > > > Yep. Other than the changes to Connectable, no other changes break > extension compatibility with 1.0.0. Very nice. So shall we try for a 1.1.0 release, next (soon)? Maybe squash a few more bugs that have surfaced from 1.0.0? And do we want to continue this versioning scheme, or continue to toss around some of the other ideas we've talked about? -Nick
Re: [DISCUSS] Beyond 1.0.0
On Tue, Jan 22, 2019 at 6:50 AM Nick Couchman wrote: > Very cool. Was 524 the only change that would push us to a major version > (2.0.0)? I can't remember off the top of my head if anything else > introduced API-relevant changes. > Yep. Other than the changes to Connectable, no other changes break extension compatibility with 1.0.0. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Mon, Jan 21, 2019 at 8:55 PM Mike Jumper wrote: > > > > I think we can allow the old connect() to be overridden and still work as > > intended by leveraging thread-local storage. We could use a thread-local > > variable to effectively pass the tokens received by the new connect() > such > > that they are available internally by SimpleConnection's implementation > of > > the old connect(). With the new version internally leveraging the old, > > users which override either will see the behavior they expect. > > > > The GuacamoleConfiguration returned by getConfiguration() would still no > > longer have tokens applied, unlike past releases where tokens were baked > in > > before each instance of SimpleConnection was created, but perhaps that's > a > > reasonable enough sacrifice? > > > > For example: > > > https://github.com/mike-jumper/guacamole-client/commit/7e67dde75155ab88af4570bcfeb3a94175093fc9 Very cool. Was 524 the only change that would push us to a major version (2.0.0)? I can't remember off the top of my head if anything else introduced API-relevant changes. -Nick
Re: [DISCUSS] Beyond 1.0.0
On Mon, Jan 21, 2019 at 5:29 PM Mike Jumper wrote: > On Sun, Jan 20, 2019 at 2:24 PM Mike Jumper wrote: > >> On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman wrote: >> >>> On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper wrote: >>> ... >>> > >>> > 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+? >>> > >>> >>> So, for a change like this (to the Connectable interface): >>> >>> https://github.com/apache/guacamole-client/commit/dfd43327618bd625bac7ce4fd35f9ccfe729ec6e#diff-1d2cb5f9d0009ea051d8a6211b20aaea >>> >>> something like this: >>> >>> https://github.com/necouchman/guacamole-client/commit/d53a6c3be576526ace6acf0432cab2480785a0ae >>> >>> ?? >>> >>> >> Something similar to that, yes. We would need default implementations for >> both old and new versions of connect(): >> >> >> https://github.com/mike-jumper/guacamole-client/commit/4a1527b1d4311bbf9d76468141dc68d02a90efa4 >> >> We would still run into trouble with the SimpleConnection class for any >> downstream uses which override the old connect(). Those overrides would >> suddenly cease to have any effect. Further, if such a downstream use also >> uses SimpleAuthenticationProvider, they might expect the provided >> GuacamoleConfiguration to already have tokens applied (the old behavior) >> rather than dynamically applied upon connect() (the new behavior). >> >> Maybe it's not possible without a compatibility layer... >> > > I think we can allow the old connect() to be overridden and still work as > intended by leveraging thread-local storage. We could use a thread-local > variable to effectively pass the tokens received by the new connect() such > that they are available internally by SimpleConnection's implementation of > the old connect(). With the new version internally leveraging the old, > users which override either will see the behavior they expect. > > The GuacamoleConfiguration returned by getConfiguration() would still no > longer have tokens applied, unlike past releases where tokens were baked in > before each instance of SimpleConnection was created, but perhaps that's a > reasonable enough sacrifice? > For example: https://github.com/mike-jumper/guacamole-client/commit/7e67dde75155ab88af4570bcfeb3a94175093fc9
Re: [DISCUSS] Beyond 1.0.0
On Sun, Jan 20, 2019 at 2:24 PM Mike Jumper wrote: > On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman wrote: > >> On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper wrote: >> ... >> > >> > 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+? >> > >> >> So, for a change like this (to the Connectable interface): >> >> https://github.com/apache/guacamole-client/commit/dfd43327618bd625bac7ce4fd35f9ccfe729ec6e#diff-1d2cb5f9d0009ea051d8a6211b20aaea >> >> something like this: >> >> https://github.com/necouchman/guacamole-client/commit/d53a6c3be576526ace6acf0432cab2480785a0ae >> >> ?? >> >> > Something similar to that, yes. We would need default implementations for > both old and new versions of connect(): > > > https://github.com/mike-jumper/guacamole-client/commit/4a1527b1d4311bbf9d76468141dc68d02a90efa4 > > We would still run into trouble with the SimpleConnection class for any > downstream uses which override the old connect(). Those overrides would > suddenly cease to have any effect. Further, if such a downstream use also > uses SimpleAuthenticationProvider, they might expect the provided > GuacamoleConfiguration to already have tokens applied (the old behavior) > rather than dynamically applied upon connect() (the new behavior). > > Maybe it's not possible without a compatibility layer... > I think we can allow the old connect() to be overridden and still work as intended by leveraging thread-local storage. We could use a thread-local variable to effectively pass the tokens received by the new connect() such that they are available internally by SimpleConnection's implementation of the old connect(). With the new version internally leveraging the old, users which override either will see the behavior they expect. The GuacamoleConfiguration returned by getConfiguration() would still no longer have tokens applied, unlike past releases where tokens were baked in before each instance of SimpleConnection was created, but perhaps that's a reasonable enough sacrifice? - Mike
Re: [DISCUSS] Beyond 1.0.0
On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman wrote: > On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper wrote: > > > On Thu, Jan 17, 2019, 13:02 Nick Couchman > > > > On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper > wrote: > > > > > > > > > > > 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+? > > > > So, for a change like this (to the Connectable interface): > > https://github.com/apache/guacamole-client/commit/dfd43327618bd625bac7ce4fd35f9ccfe729ec6e#diff-1d2cb5f9d0009ea051d8a6211b20aaea > > something like this: > > https://github.com/necouchman/guacamole-client/commit/d53a6c3be576526ace6acf0432cab2480785a0ae > > ?? > > Something similar to that, yes. We would need default implementations for both old and new versions of connect(): https://github.com/mike-jumper/guacamole-client/commit/4a1527b1d4311bbf9d76468141dc68d02a90efa4 We would still run into trouble with the SimpleConnection class for any downstream uses which override the old connect(). Those overrides would suddenly cease to have any effect. Further, if such a downstream use also uses SimpleAuthenticationProvider, they might expect the provided GuacamoleConfiguration to already have tokens applied (the old behavior) rather than dynamically applied upon connect() (the new behavior). Maybe it's not possible without a compatibility layer... > On another note, I have started looking at the changes required to support > FreeRDP 2.0. I know you asked for help on this a while back, with no > takers. It might take me 10x as long as someone else to figure it out, but > it's clear from some recent traffic on the list that it's going to be > pretty important that we support FreeRDP 2.0 going forward. So, time to > tackle it :-). Unfortunately just an hour or so into it and I already want > to run my head through a brick wall. Speaking of API compatibility, these > changes are not insignificant... Yeah, that's pretty typical in my experience of FreeRDP API changes. I did some work recently trying to abstract away the VNC support from the underlying library, and I think we can do the same with the RDP - allowing FreeRDP 1.x and 2.x to be alternative backends fo the same support. It's not the easiest thing ever, but it wasn't too horrible. I'll give it a shot. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper wrote: > On Thu, Jan 17, 2019, 13:02 Nick Couchman > > On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper wrote: > > > > > > > > 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+? > So, for a change like this (to the Connectable interface): https://github.com/apache/guacamole-client/commit/dfd43327618bd625bac7ce4fd35f9ccfe729ec6e#diff-1d2cb5f9d0009ea051d8a6211b20aaea something like this: https://github.com/necouchman/guacamole-client/commit/d53a6c3be576526ace6acf0432cab2480785a0ae ?? I assume if we wanted to do this for 2.0.0 (or 1.1.0, etc.) we'd need to go back and look at everything that's been changed in guacamole-ext and basically add these default methods for any methods where we changed the parameters being passed in? Is it just for Interfaces, or would it also be Abstract Classes within the guacamole-ext component? On another note, I have started looking at the changes required to support FreeRDP 2.0. I know you asked for help on this a while back, with no takers. It might take me 10x as long as someone else to figure it out, but it's clear from some recent traffic on the list that it's going to be pretty important that we support FreeRDP 2.0 going forward. So, time to tackle it :-). Unfortunately just an hour or so into it and I already want to run my head through a brick wall. Speaking of API compatibility, these changes are not insignificant... -Nick
Re: [DISCUSS] Beyond 1.0.0
On Thu, Jan 17, 2019, 13:02 Nick Couchman On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper wrote: > > > On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman wrote: > > > > > On Fri, Jan 11, 2019 at 8:11 AM carl harris > > 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
Re: [DISCUSS] Beyond 1.0.0
On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper wrote: > On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman wrote: > > > On Fri, Jan 11, 2019 at 8:11 AM carl harris > 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
Re: [DISCUSS] Beyond 1.0.0
On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman wrote: > On Fri, Jan 11, 2019 at 8:11 AM carl harris 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. - Mike
Re: [DISCUSS] Beyond 1.0.0
On Fri, Jan 11, 2019 at 8:11 AM carl harris wrote: > Just a thought, but perhaps we should start by considering how the > evolution of the product should be reflected in the versioning. > Agreed. > > 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? > I don't know if I would say "committed" to it, but we decided back post-0.9.14 and pre-1.0.0 that we would move forward with semantic versioning, where API-related changes are major versions (1.0.0 -> 2.0.0), feature changes are minor versions (1.0.0 -> 1.1.0), and then bug fixes are release versions (1.0.0 -> 1.0.1). I don't have the exact link at my fingertips, but the proposed/accepted proposal at the time was: - Changes which impact the overall API and thus change or break compatibility between components within the product would be major version changes. This would be most changes to guacamole-ext and guacamole-common components. - Changes which introduce new features or significant code changes to extensions, but which do not break compatibility, would be minor version changes. - Changes which are very simple, bug fixes, etc., would be release versions. I think I have accurately represented it - I'm having trouble digging up the link. > > 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? > > Again, just trying to stimulate some discussion here. > > Definitely appreciated! -Nick
Re: [DISCUSS] Beyond 1.0.0
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 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
[DISCUSS] Beyond 1.0.0
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