You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@guacamole.apache.org by Nick Couchman <vn...@apache.org> on 2019/01/11 10:16:02 UTC
[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
Re: [DISCUSS] Beyond 1.0.0
Posted by Mike Jumper <mj...@apache.org>.
On Sat, Feb 9, 2019 at 12:14 PM Nick Couchman <vn...@apache.org> 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
Posted by Nick Couchman <vn...@apache.org>.
>
> 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
Posted by Mike Jumper <mj...@apache.org>.
On Sat, Feb 2, 2019 at 4:11 PM Nick Couchman <vn...@apache.org> 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
Posted by Nick Couchman <vn...@apache.org>.
On Sat, Feb 2, 2019 at 7:02 PM Nick Couchman <vn...@apache.org> wrote:
> On Sat, Feb 2, 2019 at 2:49 PM Nick Couchman <vn...@apache.org> 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.
>
>
And maybe 637??
https://issues.apache.org/jira/browse/GUACAMOLE-637
-Nick
>
Re: [DISCUSS] Beyond 1.0.0
Posted by Nick Couchman <vn...@apache.org>.
On Sat, Feb 2, 2019 at 2:49 PM Nick Couchman <vn...@apache.org> 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
Posted by Nick Couchman <vn...@apache.org>.
>
> >
> > 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
Posted by Mike Jumper <mj...@apache.org>.
On Fri, Feb 1, 2019 at 5:42 PM Nick Couchman <vn...@apache.org> wrote:
>
> On Tue, Jan 22, 2019 at 7:57 PM Nick Couchman <vn...@apache.org> 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
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Jan 22, 2019 at 7:57 PM Nick Couchman <vn...@apache.org> 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
Posted by Nick Couchman <vn...@apache.org>.
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
Posted by Mike Jumper <mj...@apache.org>.
On Tue, Jan 22, 2019 at 4:19 PM Nick Couchman <vn...@apache.org> wrote:
> On Tue, Jan 22, 2019 at 19:10 Mike Jumper <mj...@apache.org> wrote:
>
> > On Tue, Jan 22, 2019 at 6:50 AM Nick Couchman <vn...@apache.org> 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
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Jan 22, 2019 at 19:10 Mike Jumper <mj...@apache.org> wrote:
> On Tue, Jan 22, 2019 at 6:50 AM Nick Couchman <vn...@apache.org> 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
Posted by Mike Jumper <mj...@apache.org>.
On Tue, Jan 22, 2019 at 6:50 AM Nick Couchman <vn...@apache.org> 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
Posted by Nick Couchman <vn...@apache.org>.
On Mon, Jan 21, 2019 at 8:55 PM Mike Jumper <mj...@apache.org> 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
Posted by Mike Jumper <mj...@apache.org>.
On Mon, Jan 21, 2019 at 5:29 PM Mike Jumper <mj...@apache.org> wrote:
> On Sun, Jan 20, 2019 at 2:24 PM Mike Jumper <mj...@apache.org> wrote:
>
>> On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman <vn...@apache.org> wrote:
>>
>>> On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper <mj...@apache.org> 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
Posted by Mike Jumper <mj...@apache.org>.
On Sun, Jan 20, 2019 at 2:24 PM Mike Jumper <mj...@apache.org> wrote:
> On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman <vn...@apache.org> wrote:
>
>> On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper <mj...@apache.org> 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
Posted by Mike Jumper <mj...@apache.org>.
On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman <vn...@apache.org> wrote:
> On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper <mj...@apache.org> wrote:
>
> > On Thu, Jan 17, 2019, 13:02 Nick Couchman <vnick@apache.org wrote:
> >
> > > On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper <mj...@apache.org>
> 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
Posted by Nick Couchman <vn...@apache.org>.
On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper <mj...@apache.org> wrote:
> On Thu, Jan 17, 2019, 13:02 Nick Couchman <vnick@apache.org wrote:
>
> > On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper <mj...@apache.org> 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
Posted by Mike Jumper <mj...@apache.org>.
On Thu, Jan 17, 2019, 13:02 Nick Couchman <vnick@apache.org wrote:
> On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper <mj...@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 <ce...@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
Re: [DISCUSS] Beyond 1.0.0
Posted by Nick Couchman <vn...@apache.org>.
On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper <mj...@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 <ce...@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?
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
Posted by Mike Jumper <mj...@apache.org>.
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 <ce...@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.
- Mike
Re: [DISCUSS] Beyond 1.0.0
Posted by Nick Couchman <vn...@apache.org>.
On Fri, Jan 11, 2019 at 8:11 AM carl harris <ce...@gmail.com> 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
Posted by carl harris <ce...@gmail.com>.
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