On Wed, Jul 8, 2020 at 6:21 AM Joshua C. Colp wrote:
> Greetings all,
>
> I've given this some thought in the past and thought with the impending
> branching of Asterisk 18 I'd get some input on a change to the process. The
> new major version process has evolved over time but hasn't really been
On Wed, Jul 8, 2020 at 10:24 AM Dan Jenkins wrote:
> YES YES YES.
>
I'm sorry, I didn't quite hear you. Did you say "no"? :D
> I never really got why it was done like it was...
>
Yeah, I don't really recall why either. I think it originates from a time
where we were still early to testing
On Wed, Jul 8, 2020 at 9:56 AM Jared Smith
wrote:
> On Wed, Jul 8, 2020 at 8:21 AM Joshua C. Colp wrote:
>
>> 1. It leaves a confusing area for developers where we have to ask "should
>> this go into 18.0?"
>> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
>> the other
YES YES YES.
I never really got why it was done like it was...
I agree, 4-6 weeks is good. If someone's going to take the time to upgrade
to an 18 RC then they'll be looking to test it and give feedback etc etc so
you don't need a huge amount of time... just enough to actually action bug
fixes
Greetings all,
I've given this some thought in the past and thought with the impending
branching of Asterisk 18 I'd get some input on a change to the process. The
new major version process has evolved over time but hasn't really been
changed lately. Let's look at what it is like in practice
On Wed, Jul 8, 2020 at 8:21 AM Joshua C. Colp wrote:
> 1. It leaves a confusing area for developers where we have to ask "should
> this go into 18.0?"
> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
> the other current releases have bug fixes they don't have, which has
With the current process new features can be added with tests can target
18 as soon as the branch is cut but would not go into 18.0. What would
happen with new features in this scheme, would they just get held open
in gerrit until 18.0 is branched or be accepted as normal since 18.0.0
release
On Wed, Jul 8, 2020 at 12:57 PM Corey Farrell wrote:
> With the current process new features can be added with tests can target
> 18 as soon as the branch is cut but would not go into 18.0. What would
> happen with new features in this scheme, would they just get held open in
> gerrit until
+1
I would also would approve of other potential changes to releases and the
release process but will save that for another time :-D
On Wed, Jul 8, 2020 at 7:21 AM Joshua C. Colp wrote:
> Greetings all,
>
> I've given this some thought in the past and thought with the impending
> branching of
- On Jul 8, 2020, at 8:20 AM, Joshua C. Colp wrote:
| I'd like to propose that instead of cutting the 18.0 branch on July 15th we
| simply cut the 18 branch, and that it continues to receive all bug fixes.
| Approximately a month before a target release of 18.0.0 we create the first
|
Well if it got Dan Jenkins excited :)
I dig it.
On Wed, Jul 8, 2020 at 6:25 AM Dan Jenkins wrote:
>
> YES YES YES.
>
> I never really got why it was done like it was...
>
> I agree, 4-6 weeks is good. If someone's going to take the time to upgrade to
> an 18 RC then they'll be looking to test
Hello,
On 2020-07-08 8:20 a.m., Joshua C. Colp wrote:
What do people think? Do we believe that a month out is ample enough?
The 18 branch itself will exist, so that can be used for early testing
(and likely will be). If a month isn't enough it could be moved out
further. Really I think
Today, if you create an endpoint configuration with no codecs, we create an
empty topology for it but otherwise accept it. I'm not sure what you'd use
it for though. Is there a situation where an endpoint with no codecs
_should_ be allowed or can we start rejecting those endpoint
On Wed, Jul 8, 2020 at 8:29 AM Joshua C. Colp wrote:
>
> On Wed, Jul 8, 2020 at 10:24 AM Dan Jenkins wrote:
>>
>> YES YES YES.
>
>
> I'm sorry, I didn't quite hear you. Did you say "no"? :D
>
>>
>> I never really got why it was done like it was...
>
>
> Yeah, I don't really recall why either. I
14 matches
Mail list logo
