пн, 18 февр. 2019 г. в 11:08, Emmanuel Bourg
>
> Le 16/02/2019 à 16:09, Michael Osipov a écrit :
>
> > The given approach, for whatsoever reason, performs an uppercase and
> > replaces dots with underscores. This reduces readability, but also
> > requires people (esp. package maintainers) to perfo
Am 2019-02-20 um 17:44 schrieb Mark Thomas:
On 20/02/2019 16:14, Igal Sapir wrote:
Michael,
On Mon, Feb 18, 2019 at 11:53 AM Michael Osipov wrote:
Am 2019-02-18 um 15:19 schrieb Igal Sapir:
I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
"7.0.x"). If tags will on
Mark,
On 2/20/2019 8:44 AM, Mark Thomas wrote:
On 20/02/2019 16:14, Igal Sapir wrote:
Michael,
On Mon, Feb 18, 2019 at 11:53 AM Michael Osipov wrote:
Am 2019-02-18 um 15:19 schrieb Igal Sapir:
I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
"7.0.x"). If tags wil
On 20/02/2019 16:14, Igal Sapir wrote:
> Michael,
>
> On Mon, Feb 18, 2019 at 11:53 AM Michael Osipov wrote:
>
>> Am 2019-02-18 um 15:19 schrieb Igal Sapir:
>>>
>>>
>>> I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
>>> "7.0.x"). If tags will only use the numeric vers
Michael,
On Mon, Feb 18, 2019 at 11:53 AM Michael Osipov wrote:
> Am 2019-02-18 um 15:19 schrieb Igal Sapir:
> >
> >
> > I actually prefer "tc8.5" and "tc7.0" for the branches (over "8.5.x" and
> > "7.0.x"). If tags will only use the numeric versions then this will make
> > it easy to differen
Am 2019-02-18 um 15:19 schrieb Igal Sapir:
On Mon, Feb 18, 2019 at 2:03 AM Mark Thomas wrote:
On 18/02/2019 09:13, Rémy Maucherat wrote:
On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov
wrote:
Folks,
given that we are currently in the process of migrating to Git I'd like
to propose a more
Am 2019-02-18 um 11:03 schrieb Mark Thomas:
On 18/02/2019 09:13, Rémy Maucherat wrote:
On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov wrote:
Folks,
given that we are currently in the process of migrating to Git I'd like
to propose a more readible and with the branch names consistent tag
nami
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 2/18/19 05:03, Mark Thomas wrote:
> On 18/02/2019 09:13, Rémy Maucherat wrote:
>> On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov
>> wrote:
>>
>>> Folks,
>>>
>>> given that we are currently in the process of migrating to Git
>>> I'd like
On Mon, Feb 18, 2019 at 2:03 AM Mark Thomas wrote:
> On 18/02/2019 09:13, Rémy Maucherat wrote:
> > On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov
> wrote:
> >
> >> Folks,
> >>
> >> given that we are currently in the process of migrating to Git I'd like
> >> to propose a more readible and with t
On 18/02/2019 09:13, Rémy Maucherat wrote:
> On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov wrote:
>
>> Folks,
>>
>> given that we are currently in the process of migrating to Git I'd like
>> to propose a more readible and with the branch names consistent tag
>> naming scheme.
>>
>> The given app
On Sat, Feb 16, 2019 at 4:09 PM Michael Osipov wrote:
> Folks,
>
> given that we are currently in the process of migrating to Git I'd like
> to propose a more readible and with the branch names consistent tag
> naming scheme.
>
> The given approach, for whatsoever reason, performs an uppercase an
Le 16/02/2019 à 16:09, Michael Osipov a écrit :
> The given approach, for whatsoever reason, performs an uppercase and
> replaces dots with underscores. This reduces readability, but also
> requires people (esp. package maintainers) to perform sed(1) magic to
> convert back and forth.
I agree thi
Michael,
On Sat, Feb 16, 2019 at 7:09 AM Michael Osipov wrote:
>
>
> There are bascially two approaches I'd like to discuss:
>
> Approch 1: It will reuse the branch name of the current major version,
> excluding master. Thus, we will have the following prefixes: tomcat90-,
> tomcat85-, and tomc
Folks,
given that we are currently in the process of migrating to Git I'd like
to propose a more readible and with the branch names consistent tag
naming scheme.
The given approach, for whatsoever reason, performs an uppercase and
replaces dots with underscores. This reduces readability, but
Yoav Shapira wrote:
Hi,
> Yes, it could maybe be the cleanest, but too annoying to do IMO. I
> would prefer the easy way you suggested and move current development
> to http://svn.apache.org/repos/asf/tomcat/trunk/ until there's a
> release plan and it is moved to a /tcy.y.x/trunk/ with the app
Hi,
> Yes, it could maybe be the cleanest, but too annoying to do IMO. I
> would prefer the easy way you suggested and move current development
> to http://svn.apache.org/repos/asf/tomcat/trunk/ until there's a
> release plan and it is moved to a /tcy.y.x/trunk/ with the appropriate
> name.
I
Remy Maucherat wrote:
Rainer Jung wrote:
Hi,
I think Yoav might have misunderstood your suggestion. I interprete
the branch you posted as the one, you suggest to use for the
maintenance of the existing 6.0.x source and to use trunk to proceed
with working on annotations, comet etc.
What I
Rainer Jung wrote:
Hi,
I think Yoav might have misunderstood your suggestion. I interprete the
branch you posted as the one, you suggest to use for the maintenance of
the existing 6.0.x source and to use trunk to proceed with working on
annotations, comet etc.
What I would find a little str
Hi,
I think Yoav might have misunderstood your suggestion. I interprete the
branch you posted as the one, you suggest to use for the maintenance of
the existing 6.0.x source and to use trunk to proceed with working on
annotations, comet etc.
What I would find a little strange, would be using
Yoav Shapira wrote:
Hola,
On 5/18/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
http(s)://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/tc6.0.x ?
Or
http(s)://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/annotationsAndComet
If it gets that experimental, it should go to the sandbox
Hola,
On 5/18/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
http(s)://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/tc6.0.x ?
Or
http(s)://svn.apache.org/repos/asf/tomcat/tc6.0.x/branches/annotationsAndComet
Yoav
-
To un
Remy Maucherat wrote:
Hi,
Because of the amount of proposed API changes, it could be a good idea
to start a new 6.x branch (with a short release cycle). Or is it
acceptable to do these in 6.0.x ?
The list would be:
- new Comet capabilities, with non blocking IO
- revised EE integration APIs
On May 17, 2007, at 7:46 AM, Remy Maucherat wrote:
Hi,
Because of the amount of proposed API changes, it could be a good
idea to start a new 6.x branch (with a short release cycle). Or is
it acceptable to do these in 6.0.x ?
The list would be:
- new Comet capabilities, with non blocking
Yoav Shapira wrote:
Hi,
On 5/17/07, Henri Gomez <[EMAIL PROTECTED]> wrote:
> we're calling the existing one 6.0.x,
> wouldn't it be reasonable to call the new one 6.1.x?
6.1 or 6.5 ? Like 5.0 and 5.5 :)
Exactly my point -- the version number is not something we need to
decide now ;) The bra
Hi,
On 5/17/07, Henri Gomez <[EMAIL PROTECTED]> wrote:
> we're calling the existing one 6.0.x,
> wouldn't it be reasonable to call the new one 6.1.x?
6.1 or 6.5 ? Like 5.0 and 5.5 :)
Exactly my point -- the version number is not something we need to
decide now ;) The branch can be named for
we're calling the existing one 6.0.x,
wouldn't it be reasonable to call the new one 6.1.x?
6.1 or 6.5 ? Like 5.0 and 5.5 :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Yoav Shapira wrote:
Hi,
On 5/17/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Because of the amount of proposed API changes, it could be a good idea
to start a new 6.x branch (with a short release cycle). Or is it
acceptable to do these in 6.0.x ?
Like Filip and Mladen, I would prefer
Jean-Frederic wrote:
On Thu, 2007-05-17 at 13:46 +0200, Remy Maucherat wrote:
Hi,
Because of the amount of proposed API changes, it could be a good idea
to start a new 6.x branch (with a short release cycle). Or is it
acceptable to do these in 6.0.x ?
If you make a new branch I think the
On Thu, 2007-05-17 at 13:46 +0200, Remy Maucherat wrote:
> Hi,
>
> Because of the amount of proposed API changes, it could be a good idea
> to start a new 6.x branch (with a short release cycle). Or is it
> acceptable to do these in 6.0.x ?
If you make a new branch I think the
Hi,
On 5/17/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
Because of the amount of proposed API changes, it could be a good idea
to start a new 6.x branch (with a short release cycle). Or is it
acceptable to do these in 6.0.x ?
Like Filip and Mladen, I would prefer a new branch. It&#x
Filip Hanik - Dev Lists wrote:
+1
Sure, I'd prefer the new branch, it's a good idea in the scenario where
the new changes may not be complete and we have to do a security
fix/release 6.0
But then 6.0 should be frozen for any API change.
6.1.x would work
If the 6.2 stable b
+1
Sure, I'd prefer the new branch, it's a good idea in the scenario where
the new changes may not be complete and we have to do a security
fix/release 6.0
6.1.x would work
Filip
Remy Maucherat wrote:
Hi,
Because of the amount of proposed API changes, it could be a good idea
Hi,
Because of the amount of proposed API changes, it could be a good idea
to start a new 6.x branch (with a short release cycle). Or is it
acceptable to do these in 6.0.x ?
The list would be:
- new Comet capabilities, with non blocking IO
- revised EE integration APIs (for annotation process
33 matches
Mail list logo
