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.
>
> D
>
> 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
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
> revi
On Sat, Feb 2, 2019 at 7:02 PM Nick Couchman wrote:
> 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.
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
>> iss
>
> >
> > 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/GUAC
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 be
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
>> bu
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
> > aro
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 o
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.
> >
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
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
> > th
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
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 inhe
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 comp
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
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
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 ve
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 somethin
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 spe
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
pro
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 ofte
23 matches
Mail list logo