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.
>
>
>
> 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,
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
>
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
>>
>
> >
> > 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:
> >
> >
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
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
>>
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
> >
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
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
> >
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.
>>> >
>>> >
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
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
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
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
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
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
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
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
21 matches
Mail list logo
