Re: asyncweb client 1.0 work
On Thu, Jun 18, 2009 at 10:46 PM, Emmanuel Lecharny elecha...@apache.orgwrote: 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=682452content-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
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=682452content-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
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 elecha...@apache.orgwrote: 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=682452content-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
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
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
Le Thu, 18 Jun 2009 13:47:20 +0200, Emmanuel Lecharny elecha...@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 signature.asc Description: PGP signature
Re: asyncweb client 1.0 work
Julien Vermillard wrote: Le Thu, 18 Jun 2009 13:47:20 +0200, Emmanuel Lecharny elecha...@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
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 elecha...@apache.orgwrote: Julien Vermillard wrote: Le Thu, 18 Jun 2009 13:47:20 +0200, Emmanuel Lecharny elecha...@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
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
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
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
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 elecha...@gmail.comwrote: 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
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
+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
