You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Sangjin Lee <sj...@apache.org> on 2009/06/17 23:33:29 UTC
asyncweb client 1.0 work
Hi,
We've been actively using the asyncweb client (the 1.0 version) in
production for a while, and I have a number of pent-up changes I wish to
contribute back. Our company also has a couple of critical enhancements in
mind, and I would like to see that done on this 1.0 branch.
I know that there is a trunk version but it has been dormant with little
activity for quite some time now (and I shoulder part of the blame as a
committer). But we've come to a point where we can no longer defer making
these changes and enhancements until the trunk version becomes fully baked
while there is a great production that's production ready.
So, in light of that, I'd like to open up the asyncweb client 1.0 branch and
contribute these bug fixes as well as a couple of enhancements in the
future. There was no official release from that branch anyway, and I feel
this is something that will add a lot of value to many people.
Please let me know if you have objections, and we can discuss. I'd also
like to you those of you who are using the asyncweb client in any way and
chime in on the discussion. Thanks much!
Regards,
Sangjin
Re: asyncweb client 1.0 work
Posted by Jeff Genender <jg...@apache.org>.
+1... can't wait to see the contribution!
Jeff
On Jun 17, 2009, at 3:33 PM, Sangjin Lee wrote:
> Hi,
> We've been actively using the asyncweb client (the 1.0 version) in
> production for a while, and I have a number of pent-up changes I
> wish to
> contribute back. Our company also has a couple of critical
> enhancements in
> mind, and I would like to see that done on this 1.0 branch.
>
> I know that there is a trunk version but it has been dormant with
> little
> activity for quite some time now (and I shoulder part of the blame
> as a
> committer). But we've come to a point where we can no longer defer
> making
> these changes and enhancements until the trunk version becomes fully
> baked
> while there is a great production that's production ready.
>
> So, in light of that, I'd like to open up the asyncweb client 1.0
> branch and
> contribute these bug fixes as well as a couple of enhancements in the
> future. There was no official release from that branch anyway, and
> I feel
> this is something that will add a lot of value to many people.
>
> Please let me know if you have objections, and we can discuss. I'd
> also
> like to you those of you who are using the asyncweb client in any
> way and
> chime in on the discussion. Thanks much!
>
> Regards,
> Sangjin
Re: asyncweb client 1.0 work
Posted by Sangjin Lee <sj...@gmail.com>.
OK thanks. I'll first clean up the version numbers according to the
discussion we had so far.
Thanks,
Sangjin
On Fri, Jun 19, 2009 at 12:47 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Sangjin Lee wrote:
>
>> we can, but as the client depends on the current trunk, as soon as we do
>>> some modifciation in trunk, the branch will be dead.
>>>
>>>
>>
>>
>> Where do you see the (1.0 branch) client dependency on the asyncweb trunk?
>> I'm looking at the pom.xml (
>>
>> https://svn.apache.org/viewvc/mina/asyncweb/branches/1.0/client/pom.xml?revision=682452&content-type=text%2Fplain
>> )
>> but I don't see a dependency on the asyncweb trunk (only mina 1.1.x and
>> other libraries). Maybe I'm being thick...
>>
>>
> I was refering to trunk's client :
> https://svn.apache.org/viewvc/mina/asyncweb/trunk/client/pom.xml?view=co
>
> So in your case (1.0), this is not a problem. However, it may be
> interesting to see the client as a separated project anyway.
>
>
>>
>>
>>> I suggest we go a bit further and copy all what we have in trunk in the
>>> 1.0
>>> branch.
>>>
>>> Now, we should create 3 sub projects in this branch, one for client (what
>>> you want to work on), the server and commons. They will be separated
>>> projects.
>>>
>>> here is the structure I forsee :
>>>
>>> /
>>> branches
>>> 1.0-mina1
>>> client
>>> commons
>>> server
>>> pom.xml
>>> NOTICE
>>> README
>>> tags
>>> <nothing atm, but hopefully 1.0 soon>
>>> trunk
>>> client
>>> commons
>>> server
>>> pom.xml
>>> NOTICE
>>> README
>>>
>>>
>>> --
>>> --
>>> cordialement, regards,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>> directory.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: asyncweb client 1.0 work
Posted by Emmanuel Lecharny <el...@apache.org>.
Sangjin Lee wrote:
>> we can, but as the client depends on the current trunk, as soon as we do
>> some modifciation in trunk, the branch will be dead.
>>
>
>
> Where do you see the (1.0 branch) client dependency on the asyncweb trunk?
> I'm looking at the pom.xml (
> https://svn.apache.org/viewvc/mina/asyncweb/branches/1.0/client/pom.xml?revision=682452&content-type=text%2Fplain)
> but I don't see a dependency on the asyncweb trunk (only mina 1.1.x and
> other libraries). Maybe I'm being thick...
>
I was refering to trunk's client :
https://svn.apache.org/viewvc/mina/asyncweb/trunk/client/pom.xml?view=co
So in your case (1.0), this is not a problem. However, it may be
interesting to see the client as a separated project anyway.
>
>
>> I suggest we go a bit further and copy all what we have in trunk in the 1.0
>> branch.
>>
>> Now, we should create 3 sub projects in this branch, one for client (what
>> you want to work on), the server and commons. They will be separated
>> projects.
>>
>> here is the structure I forsee :
>>
>> /
>> branches
>> 1.0-mina1
>> client
>> commons
>> server
>> pom.xml
>> NOTICE
>> README
>> tags
>> <nothing atm, but hopefully 1.0 soon>
>> trunk
>> client
>> commons
>> server
>> pom.xml
>> NOTICE
>> README
>>
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
>>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: asyncweb client 1.0 work
Posted by Sangjin Lee <sj...@gmail.com>.
On Thu, Jun 18, 2009 at 10:46 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> Sangjin Lee wrote:
>
>> The versions are definitely messy, and we need to sort it out.
>> How about calling the trunk the "2.0" version as it is based on mina 2.0.x
>> (easier to remember)? Let's keep the 1.0 version as is. But let's name
>> it
>> "1.0-mina1".
>>
>>
> The trunk will contain the 2.0 version. The name will remain trunk, though.
> We will have to change the pom.xml to reflect this modification, once the
> 1.0-mina1 branch will be created. (note that the mina1 suffix is just used
> as a reminder)
I agree. That's what I meant too. :)
>
> As for subprojects,
>> the 1.0 client does not have separate common, client, and server
>> projects. That is only in the trunk pom.xml. And this actually goes
>> to the heart of this point. The common-client-server division is based on
>> the vision that both the client and server share a significant portion of
>> code.
>>
>> As it stands right now,
>> the 1.0 branch has only the client portion, and there is no breakout
>> of the common piece. If possible, I'd like to keep it that way...
>>
>>
> we can, but as the client depends on the current trunk, as soon as we do
> some modifciation in trunk, the branch will be dead.
Where do you see the (1.0 branch) client dependency on the asyncweb trunk?
I'm looking at the pom.xml (
https://svn.apache.org/viewvc/mina/asyncweb/branches/1.0/client/pom.xml?revision=682452&content-type=text%2Fplain)
but I don't see a dependency on the asyncweb trunk (only mina 1.1.x and
other libraries). Maybe I'm being thick...
>
>
> I suggest we go a bit further and copy all what we have in trunk in the 1.0
> branch.
>
> Now, we should create 3 sub projects in this branch, one for client (what
> you want to work on), the server and commons. They will be separated
> projects.
>
> here is the structure I forsee :
>
> /
> branches
> 1.0-mina1
> client
> commons
> server
> pom.xml
> NOTICE
> README
> tags
> <nothing atm, but hopefully 1.0 soon>
> trunk
> client
> commons
> server
> pom.xml
> NOTICE
> README
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: asyncweb client 1.0 work
Posted by Emmanuel Lecharny <el...@apache.org>.
Sangjin Lee wrote:
> The versions are definitely messy, and we need to sort it out.
> How about calling the trunk the "2.0" version as it is based on mina 2.0.x
> (easier to remember)? Let's keep the 1.0 version as is. But let's name it
> "1.0-mina1".
>
The trunk will contain the 2.0 version. The name will remain trunk,
though. We will have to change the pom.xml to reflect this modification,
once the 1.0-mina1 branch will be created. (note that the mina1 suffix
is just used as a reminder)
> As for subprojects,
> the 1.0 client does not have separate common, client, and server
> projects. That is only in the trunk pom.xml. And this actually goes
> to the heart of this point. The common-client-server division is based on
> the vision that both the client and server share a significant portion of
> code.
>
> As it stands right now,
> the 1.0 branch has only the client portion, and there is no breakout
> of the common piece. If possible, I'd like to keep it that way...
>
we can, but as the client depends on the current trunk, as soon as we do
some modifciation in trunk, the branch will be dead.
I suggest we go a bit further and copy all what we have in trunk in the
1.0 branch.
Now, we should create 3 sub projects in this branch, one for client
(what you want to work on), the server and commons. They will be
separated projects.
here is the structure I forsee :
/
branches
1.0-mina1
client
commons
server
pom.xml
NOTICE
README
tags
<nothing atm, but hopefully 1.0 soon>
trunk
client
commons
server
pom.xml
NOTICE
README
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: asyncweb client 1.0 work
Posted by Sangjin Lee <sj...@gmail.com>.
The versions are definitely messy, and we need to sort it out.
How about calling the trunk the "2.0" version as it is based on mina 2.0.x
(easier to remember)? Let's keep the 1.0 version as is. But let's name it
"1.0-mina1".
As for subprojects,
the 1.0 client does not have separate common, client, and server
projects. That is only in the trunk pom.xml. And this actually goes
to the heart of this point. The common-client-server division is based on
the vision that both the client and server share a significant portion of
code.
As it stands right now,
the 1.0 branch has only the client portion, and there is no breakout
of the common piece. If possible, I'd like to keep it that way...
Thoughts?
Regards,
Sangjin
On Thu, Jun 18, 2009 at 5:32 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Julien Vermillard wrote:
>
>> Le Thu, 18 Jun 2009 13:47:20 +0200,
>> Emmanuel Lecharny <el...@apache.org> a écrit :
>>
>>
>>
>>> Rick McGuire wrote:
>>>
>>>
>>>> Emmanuel Lecharny wrote:
>>>>
>>>>
>>>>> Sangjin Lee wrote:
>>>>>
>>>>>
>>>>>> Thanks. I'll also check the trunk to see if changes are
>>>>>> applicable to the
>>>>>> trunk.
>>>>>> I'm not quite sure I understand what you mean by renaming it to
>>>>>> 1.0-trunk.
>>>>>> The svn URL is .../mina/asyncweb/branches/1.0/... Do you mean
>>>>>> to rename it
>>>>>> to .../mina/asyncweb/trunk/1.0/...?
>>>>>>
>>>>>>
>>>>> Well, it's more a question about what we see as a branch.
>>>>>
>>>>> Usually, when releasing, we start by freezing the trunk into a branch,
>>>>> like what we did in 1.0
>>>>> and if we want to start a new version, we do it in another branch.
>>>>>
>>>>> In your case, the 1.0 branch is not a version, it's just a target.
>>>>> In order to avoid confusion with a frozen version, it should be
>>>>> named 1.0-trunk.
>>>>>
>>>>> Hope it's clearer ?!
>>>>>
>>>>>
>>>>>
>>>> I think I'm as confused as Sangjin. Should this be
>>>> ".../mina/asyncweb/1.0-trunk/" as opposed to ".../mina/asyncweb/trunk/",
>>>> which is the 2.0 version? Also, should the existing branch be left frozen,
>>>> and this new working trunk be created as a copy of the frozen branch?
>>>>
>>>> I'm also +1 on this happening on the 1.0 branch. The 2.0 version
>>>> does not really look production-ready, and there were a lot of
>>>> proposed changes to that version that have never been implemented,
>>>> so it isn't really clear where things stand with that. Having some
>>>> new features implemented on a version that clearly has been used in
>>>> a production environment could only be a good thing.
>>>>
>>>>
>>> Ok, let me clarified what I tried to explain at 2 am yesterday ;) May
>>> be I was not correct too...
>>>
>>> - We have trunk, which contains the latest version (in our case, AsyncWeb
>>> with MINA 2.0. It currently contains the 0.9.0-SNAPSHOT
>>> version.
>>> - We have a tags directory, which is currently empty, as we didn't
>>> released any version yet.
>>> - And we have the branches directory, containing something called
>>> 1.0, which is the asyncweb client with is currently at version
>>> 1.0.0-SNAPSHOT (per its pom.xml)
>>>
>>> It's a bit of a mess. The branches/1.0 does not contain *anything*
>>> close to a 1.0 release of Asyncweb, it's just containing an asyncweb
>>> subproject named "client", which depends on some other asyncweb subproject
>>> named "common-asyncweb", presently available in trunk.
>>>
>>> If we are to release the asyncweb client 1.0, fine, but we have first
>>> to release the async-common subproject (or to release them at the
>>> same time).
>>>
>>> So in other word, starting from the branches/1.0 seems really not a
>>> good idea.
>>>
>>> Forget about the 1.0-trunk idea I pushed at first, this was confusion and
>>> probably totally stupid.
>>>
>>> So, what do we do ? Sangjin needs a 1.0 release of the client, with
>>> MINA 1.1.7. We need to get this done, probably by creating a branch
>>> named 1.0-mina1, and get it built and released. If we don't need the
>>> server, because it's not ready to be released, then we need to split
>>> the project in three parts :
>>> - commons
>>> - server
>>> - client
>>>
>>> each with its version. Nothing complicated, just need a bit of
>>> organization.
>>>
>>> wdyt ?
>>>
>>>
>>>
>>
>> So TRUNK version need to be 1.5-SNAPSHOT (or 2.0) in place of 0.9
>>
>>
>
> Probably 2.0-M1...
>
>> Julien
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: asyncweb client 1.0 work
Posted by Emmanuel Lecharny <el...@apache.org>.
Julien Vermillard wrote:
> Le Thu, 18 Jun 2009 13:47:20 +0200,
> Emmanuel Lecharny <el...@apache.org> a écrit :
>
>
>> Rick McGuire wrote:
>>
>>> Emmanuel Lecharny wrote:
>>>
>>>> Sangjin Lee wrote:
>>>>
>>>>> Thanks. I'll also check the trunk to see if changes are
>>>>> applicable to the
>>>>> trunk.
>>>>> I'm not quite sure I understand what you mean by renaming it to
>>>>> 1.0-trunk.
>>>>> The svn URL is .../mina/asyncweb/branches/1.0/... Do you mean
>>>>> to rename it
>>>>> to .../mina/asyncweb/trunk/1.0/...?
>>>>>
>>>>>
>>>> Well, it's more a question about what we see as a branch.
>>>>
>>>> Usually, when releasing, we start by freezing the trunk into a
>>>> branch, like what we did in 1.0
>>>> and if we want to start a new version, we do it in another branch.
>>>>
>>>> In your case, the 1.0 branch is not a version, it's just a target.
>>>> In order to avoid confusion with a frozen version, it should be
>>>> named 1.0-trunk.
>>>>
>>>> Hope it's clearer ?!
>>>>
>>>>
>>> I think I'm as confused as Sangjin. Should this be
>>> ".../mina/asyncweb/1.0-trunk/" as opposed to
>>> ".../mina/asyncweb/trunk/", which is the 2.0 version? Also, should
>>> the existing branch be left frozen, and this new working trunk be
>>> created as a copy of the frozen branch?
>>>
>>> I'm also +1 on this happening on the 1.0 branch. The 2.0 version
>>> does not really look production-ready, and there were a lot of
>>> proposed changes to that version that have never been implemented,
>>> so it isn't really clear where things stand with that. Having some
>>> new features implemented on a version that clearly has been used in
>>> a production environment could only be a good thing.
>>>
>> Ok, let me clarified what I tried to explain at 2 am yesterday ;) May
>> be I was not correct too...
>>
>> - We have trunk, which contains the latest version (in our case,
>> AsyncWeb with MINA 2.0. It currently contains the 0.9.0-SNAPSHOT
>> version.
>> - We have a tags directory, which is currently empty, as we didn't
>> released any version yet.
>> - And we have the branches directory, containing something called
>> 1.0, which is the asyncweb client with is currently at version
>> 1.0.0-SNAPSHOT (per its pom.xml)
>>
>> It's a bit of a mess. The branches/1.0 does not contain *anything*
>> close to a 1.0 release of Asyncweb, it's just containing an asyncweb
>> subproject named "client", which depends on some other asyncweb
>> subproject named "common-asyncweb", presently available in trunk.
>>
>> If we are to release the asyncweb client 1.0, fine, but we have first
>> to release the async-common subproject (or to release them at the
>> same time).
>>
>> So in other word, starting from the branches/1.0 seems really not a
>> good idea.
>>
>> Forget about the 1.0-trunk idea I pushed at first, this was confusion
>> and probably totally stupid.
>>
>> So, what do we do ? Sangjin needs a 1.0 release of the client, with
>> MINA 1.1.7. We need to get this done, probably by creating a branch
>> named 1.0-mina1, and get it built and released. If we don't need the
>> server, because it's not ready to be released, then we need to split
>> the project in three parts :
>> - commons
>> - server
>> - client
>>
>> each with its version. Nothing complicated, just need a bit of
>> organization.
>>
>> wdyt ?
>>
>>
>
> So TRUNK version need to be 1.5-SNAPSHOT (or 2.0) in place of 0.9
>
Probably 2.0-M1...
> Julien
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: asyncweb client 1.0 work
Posted by Julien Vermillard <jv...@archean.fr>.
Le Thu, 18 Jun 2009 13:47:20 +0200,
Emmanuel Lecharny <el...@apache.org> a écrit :
> Rick McGuire wrote:
> > Emmanuel Lecharny wrote:
> >> Sangjin Lee wrote:
> >>> Thanks. I'll also check the trunk to see if changes are
> >>> applicable to the
> >>> trunk.
> >>> I'm not quite sure I understand what you mean by renaming it to
> >>> 1.0-trunk.
> >>> The svn URL is .../mina/asyncweb/branches/1.0/... Do you mean
> >>> to rename it
> >>> to .../mina/asyncweb/trunk/1.0/...?
> >>>
> >> Well, it's more a question about what we see as a branch.
> >>
> >> Usually, when releasing, we start by freezing the trunk into a
> >> branch, like what we did in 1.0
> >> and if we want to start a new version, we do it in another branch.
> >>
> >> In your case, the 1.0 branch is not a version, it's just a target.
> >> In order to avoid confusion with a frozen version, it should be
> >> named 1.0-trunk.
> >>
> >> Hope it's clearer ?!
> >>
> > I think I'm as confused as Sangjin. Should this be
> > ".../mina/asyncweb/1.0-trunk/" as opposed to
> > ".../mina/asyncweb/trunk/", which is the 2.0 version? Also, should
> > the existing branch be left frozen, and this new working trunk be
> > created as a copy of the frozen branch?
> >
> > I'm also +1 on this happening on the 1.0 branch. The 2.0 version
> > does not really look production-ready, and there were a lot of
> > proposed changes to that version that have never been implemented,
> > so it isn't really clear where things stand with that. Having some
> > new features implemented on a version that clearly has been used in
> > a production environment could only be a good thing.
>
> Ok, let me clarified what I tried to explain at 2 am yesterday ;) May
> be I was not correct too...
>
> - We have trunk, which contains the latest version (in our case,
> AsyncWeb with MINA 2.0. It currently contains the 0.9.0-SNAPSHOT
> version.
> - We have a tags directory, which is currently empty, as we didn't
> released any version yet.
> - And we have the branches directory, containing something called
> 1.0, which is the asyncweb client with is currently at version
> 1.0.0-SNAPSHOT (per its pom.xml)
>
> It's a bit of a mess. The branches/1.0 does not contain *anything*
> close to a 1.0 release of Asyncweb, it's just containing an asyncweb
> subproject named "client", which depends on some other asyncweb
> subproject named "common-asyncweb", presently available in trunk.
>
> If we are to release the asyncweb client 1.0, fine, but we have first
> to release the async-common subproject (or to release them at the
> same time).
>
> So in other word, starting from the branches/1.0 seems really not a
> good idea.
>
> Forget about the 1.0-trunk idea I pushed at first, this was confusion
> and probably totally stupid.
>
> So, what do we do ? Sangjin needs a 1.0 release of the client, with
> MINA 1.1.7. We need to get this done, probably by creating a branch
> named 1.0-mina1, and get it built and released. If we don't need the
> server, because it's not ready to be released, then we need to split
> the project in three parts :
> - commons
> - server
> - client
>
> each with its version. Nothing complicated, just need a bit of
> organization.
>
> wdyt ?
>
So TRUNK version need to be 1.5-SNAPSHOT (or 2.0) in place of 0.9
Julien
Re: asyncweb client 1.0 work
Posted by Emmanuel Lecharny <el...@apache.org>.
Rick McGuire wrote:
> Emmanuel Lecharny wrote:
>> Sangjin Lee wrote:
>>> Thanks. I'll also check the trunk to see if changes are applicable
>>> to the
>>> trunk.
>>> I'm not quite sure I understand what you mean by renaming it to
>>> 1.0-trunk.
>>> The svn URL is .../mina/asyncweb/branches/1.0/... Do you mean to
>>> rename it
>>> to .../mina/asyncweb/trunk/1.0/...?
>>>
>> Well, it's more a question about what we see as a branch.
>>
>> Usually, when releasing, we start by freezing the trunk into a
>> branch, like what we did in 1.0
>> and if we want to start a new version, we do it in another branch.
>>
>> In your case, the 1.0 branch is not a version, it's just a target. In
>> order to avoid confusion with a frozen version, it should be named
>> 1.0-trunk.
>>
>> Hope it's clearer ?!
>>
> I think I'm as confused as Sangjin. Should this be
> ".../mina/asyncweb/1.0-trunk/" as opposed to
> ".../mina/asyncweb/trunk/", which is the 2.0 version? Also, should
> the existing branch be left frozen, and this new working trunk be
> created as a copy of the frozen branch?
>
> I'm also +1 on this happening on the 1.0 branch. The 2.0 version does
> not really look production-ready, and there were a lot of proposed
> changes to that version that have never been implemented, so it isn't
> really clear where things stand with that. Having some new features
> implemented on a version that clearly has been used in a production
> environment could only be a good thing.
Ok, let me clarified what I tried to explain at 2 am yesterday ;) May be
I was not correct too...
- We have trunk, which contains the latest version (in our case,
AsyncWeb with MINA 2.0. It currently contains the 0.9.0-SNAPSHOT version.
- We have a tags directory, which is currently empty, as we didn't
released any version yet.
- And we have the branches directory, containing something called 1.0,
which is the asyncweb client with is currently at version 1.0.0-SNAPSHOT
(per its pom.xml)
It's a bit of a mess. The branches/1.0 does not contain *anything* close
to a 1.0 release of Asyncweb, it's just containing an asyncweb
subproject named "client", which depends on some other asyncweb
subproject named "common-asyncweb", presently available in trunk.
If we are to release the asyncweb client 1.0, fine, but we have first to
release the async-common subproject (or to release them at the same time).
So in other word, starting from the branches/1.0 seems really not a good
idea.
Forget about the 1.0-trunk idea I pushed at first, this was confusion
and probably totally stupid.
So, what do we do ? Sangjin needs a 1.0 release of the client, with MINA
1.1.7. We need to get this done, probably by creating a branch named
1.0-mina1, and get it built and released. If we don't need the server,
because it's not ready to be released, then we need to split the project
in three parts :
- commons
- server
- client
each with its version. Nothing complicated, just need a bit of organization.
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: asyncweb client 1.0 work
Posted by Rick McGuire <ri...@gmail.com>.
Emmanuel Lecharny wrote:
> Sangjin Lee wrote:
>> Thanks. I'll also check the trunk to see if changes are applicable
>> to the
>> trunk.
>> I'm not quite sure I understand what you mean by renaming it to
>> 1.0-trunk.
>> The svn URL is .../mina/asyncweb/branches/1.0/... Do you mean to
>> rename it
>> to .../mina/asyncweb/trunk/1.0/...?
>>
> Well, it's more a question about what we see as a branch.
>
> Usually, when releasing, we start by freezing the trunk into a branch,
> like what we did in 1.0
> and if we want to start a new version, we do it in another branch.
>
> In your case, the 1.0 branch is not a version, it's just a target. In
> order to avoid confusion with a frozen version, it should be named
> 1.0-trunk.
>
> Hope it's clearer ?!
>
I think I'm as confused as Sangjin. Should this be
".../mina/asyncweb/1.0-trunk/" as opposed to ".../mina/asyncweb/trunk/",
which is the 2.0 version? Also, should the existing branch be left
frozen, and this new working trunk be created as a copy of the frozen
branch?
I'm also +1 on this happening on the 1.0 branch. The 2.0 version does
not really look production-ready, and there were a lot of proposed
changes to that version that have never been implemented, so it isn't
really clear where things stand with that. Having some new features
implemented on a version that clearly has been used in a production
environment could only be a good thing.
Rick
Re: asyncweb client 1.0 work
Posted by Emmanuel Lecharny <el...@apache.org>.
Sangjin Lee wrote:
> Thanks. I'll also check the trunk to see if changes are applicable to the
> trunk.
> I'm not quite sure I understand what you mean by renaming it to 1.0-trunk.
> The svn URL is .../mina/asyncweb/branches/1.0/... Do you mean to rename it
> to .../mina/asyncweb/trunk/1.0/...?
>
Well, it's more a question about what we see as a branch.
Usually, when releasing, we start by freezing the trunk into a branch,
like what we did in 1.0
and if we want to start a new version, we do it in another branch.
In your case, the 1.0 branch is not a version, it's just a target. In
order to avoid confusion with a frozen version, it should be named
1.0-trunk.
Hope it's clearer ?!
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: asyncweb client 1.0 work
Posted by Sangjin Lee <sj...@gmail.com>.
Thanks. I'll also check the trunk to see if changes are applicable to the
trunk.
I'm not quite sure I understand what you mean by renaming it to 1.0-trunk.
The svn URL is .../mina/asyncweb/branches/1.0/... Do you mean to rename it
to .../mina/asyncweb/trunk/1.0/...?
Also, please note that some fixes/enhancements probably will change APIs.
Wanted to make sure that is clear...
Thanks,
Sangjin
On Wed, Jun 17, 2009 at 2:49 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Sangjin Lee wrote:
>
>> Hi,
>> We've been actively using the asyncweb client (the 1.0 version) in
>> production for a while, and I have a number of pent-up changes I wish to
>> contribute back. Our company also has a couple of critical enhancements
>> in
>> mind, and I would like to see that done on this 1.0 branch.
>>
>> I know that there is a trunk version but it has been dormant with little
>> activity for quite some time now (and I shoulder part of the blame as a
>> committer). But we've come to a point where we can no longer defer making
>> these changes and enhancements until the trunk version becomes fully baked
>> while there is a great production that's production ready.
>>
>> So, in light of that, I'd like to open up the asyncweb client 1.0 branch
>> and
>> contribute these bug fixes as well as a couple of enhancements in the
>> future. There was no official release from that branch anyway, and I feel
>> this is something that will add a lot of value to many people.
>>
>> Please let me know if you have objections, and we can discuss. I'd also
>> like to you those of you who are using the asyncweb client in any way and
>> chime in on the discussion. Thanks much!
>>
>>
>
> It's a branch, it's not a tag, and trunk has moved toward MINA 2.0. So I
> see no objection for working in 1.0 branch, except that it should be renamed
> 1.0-trunk, in order to avoid confusion.
>
> Last, not least, it would be interesting to inject the patches in trunk
> too.
>
> Thanks !
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: asyncweb client 1.0 work
Posted by Emmanuel Lecharny <el...@gmail.com>.
Sangjin Lee wrote:
> Hi,
> We've been actively using the asyncweb client (the 1.0 version) in
> production for a while, and I have a number of pent-up changes I wish to
> contribute back. Our company also has a couple of critical enhancements in
> mind, and I would like to see that done on this 1.0 branch.
>
> I know that there is a trunk version but it has been dormant with little
> activity for quite some time now (and I shoulder part of the blame as a
> committer). But we've come to a point where we can no longer defer making
> these changes and enhancements until the trunk version becomes fully baked
> while there is a great production that's production ready.
>
> So, in light of that, I'd like to open up the asyncweb client 1.0 branch and
> contribute these bug fixes as well as a couple of enhancements in the
> future. There was no official release from that branch anyway, and I feel
> this is something that will add a lot of value to many people.
>
> Please let me know if you have objections, and we can discuss. I'd also
> like to you those of you who are using the asyncweb client in any way and
> chime in on the discussion. Thanks much!
>
It's a branch, it's not a tag, and trunk has moved toward MINA 2.0. So I
see no objection for working in 1.0 branch, except that it should be
renamed 1.0-trunk, in order to avoid confusion.
Last, not least, it would be interesting to inject the patches in trunk too.
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org