Re: [net] Branching
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: Daniel, I agree with all your ideas, but it seems to me you can branch from any tagged point in the revision history so I'm not sure what the idea is behind deleting/renaming the tags. All I was getting at was what to name the tag. My understanding was that a tag needs to be created as a branch. I should have used a concrete example. I was asking which of: cvs rtag -b -r NET_1_0_0 NET_1_1_0_MAINTENANCE jakarta-commons/net or cvs rtag -b -r NET_1_0_0 NET_FOO jakarta-commons/net cvs rtag -d NET_1_0_0 jakarta-commons/net cvs rtag -b -r NET_FOO NET_1_0_0 jakarta-commons/net cvs rtag -d NET_FOO we wanted to go with (NET_1_1_0_MAINTENANCE is just for example purposes; any other name indicating it's a branch will do). As Noel said, this stuff is easier with Subversion. Given that, as per Steve's message, we can make 1.1 compatibilty changes on HEAD, release and tag, and branch from that point in the future when/if there are bug fixes required? +1. That's easier and avoids the issue altogether. I guess we'd make NET_1_1_1 a branch tag in that case. I've got JDK 1.1.8v1 lying around on my development server if you want me to hunt for and correct any other 1.1 incompatibilities. Otherwise, if Steve's game, he could do it pretty quickly and get on with his work. I won't be back home until tomorrow afternoon and my currently erratic email polling combined with my being subscribed to the mailing list digest means I won't be able to act on anything until tomorrow afternoon. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
On Fri, 2 Jan 2004, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: Daniel, I agree with all your ideas, but it seems to me you can branch from any tagged point in the revision history so I'm not sure what the idea is behind deleting/renaming the tags. All I was getting at was what to name the tag. My understanding was that a tag needs to be created as a branch. I should have used Sorry for jumping in here without having been following the thread (and without having the older messages to refer to any more). However, I wanted to point out that there are two distinct types of tags in CVS. Branches affect future commits, and are harder to change your mind about after the fact. Labels are just that - a label at a particular point in time - and can pretty much be moved around at will after the fact. If you already knew that, sorry for bothering you. ;-) -- Martin Cooper a concrete example. I was asking which of: cvs rtag -b -r NET_1_0_0 NET_1_1_0_MAINTENANCE jakarta-commons/net or cvs rtag -b -r NET_1_0_0 NET_FOO jakarta-commons/net cvs rtag -d NET_1_0_0 jakarta-commons/net cvs rtag -b -r NET_FOO NET_1_0_0 jakarta-commons/net cvs rtag -d NET_FOO we wanted to go with (NET_1_1_0_MAINTENANCE is just for example purposes; any other name indicating it's a branch will do). As Noel said, this stuff is easier with Subversion. Given that, as per Steve's message, we can make 1.1 compatibilty changes on HEAD, release and tag, and branch from that point in the future when/if there are bug fixes required? +1. That's easier and avoids the issue altogether. I guess we'd make NET_1_1_1 a branch tag in that case. I've got JDK 1.1.8v1 lying around on my development server if you want me to hunt for and correct any other 1.1 incompatibilities. Otherwise, if Steve's game, he could do it pretty quickly and get on with his work. I won't be back home until tomorrow afternoon and my currently erratic email polling combined with my being subscribed to the mailing list digest means I won't be able to act on anything until tomorrow afternoon. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
In message [EMAIL PROTECTED], Martin Cooper writes: On Fri, 2 Jan 2004, Daniel F. Savarese wrote: All I was getting at was what to name the tag. My understanding was that a tag needs to be created as a branch. I should have used ... to point out that there are two distinct types of tags in CVS. Branches affect future commits, and are harder to change your mind about after the In the context of the discussion, I should have said either that the tag (meaning the tag we were talking about) or that a branch tag (meaning any branch tag) needs to be created as a branch (meaning using -b). Without my saying that, it does sound like I'm saying the wrong thing. Anyway, there's no harm (and probably some help, given my lack of clarity) in your clarifying it and I may still be wrong about the roundabout way of changing a label to a branch being the only way to use an existing CVS non-branch tag as a branch tag. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
Daniel, I agree with all your ideas, but it seems to me you can branch from any tagged point in the revision history so I'm not sure what the idea is behind deleting/renaming the tags. http://www.cvshome.org/docs/manual/cvs-1.11.10/cvs_5.html#SEC56 Given that, as per Steve's message, we can make 1.1 compatibilty changes on HEAD, release and tag, and branch from that point in the future when/if there are bug fixes required? It's early New Year's morning, so my head may be a bit foggy! On Wed, 31 Dec 2003 23:52:45 -0500, Daniel F. Savarese [EMAIL PROTECTED] said: I wrote: Sanity check the steps to make sure this is what we want: o rename NET_1_1_0 tag to something else, let's say FOO o tag FOO as NET_1_1_0, this time with the -b flag to make it a branch tag I left out delete the FOO tag ... If that seems like not a good thing, another option is to tag the NET_1_1_0 snapshot with NET_1_1_0_MAINTENANCE or some such tag for the 1.1 maintenance branch and leave the existing NET_1_1_0 tag alone. I forgot to indicate what I favor. Only because I haven't thought of any arguments against it, I favor the first method (change NET_1_1_0 to a 'cvs tag -b' branch tag). The second approach is safer because it doesn't run the risk of screwing up anything and I don't object to it. The only con I can think of to the second approach is that having two tags with NET_1_1_0 in them may be confusing. I don't think I've ever retroactively branched after tagging with CVS (usually, for me at least, branching is premeditated), which is why I don't have a strong preference. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] Branching
I like the idea of supporting older jvm versions while moving forward with new development. I would suggest we do the branching slightly different than you have described. I've found that keeping normal development happening on the HEAD branch to be more beneficial than an experimental branch. We would branch for bug fixes only, all new development proceeds on HEAD. After we make a 1.1 compatible release and tag, that will be the branch point for any 1.1 fixes. Next we can make a release with 1.2 support and tag, that will be the branch point for any 1.2 related fixes. All development then proceeds on HEAD. Its just a suggestion. I can live with an experimental branch also, just in other projects I've been involved with, if HEAD isn't the focal point of new development, it get confusing where to put stuff, what is working, etc. On Wed, 31 Dec 2003 11:14:56 -0500, Daniel F. Savarese [EMAIL PROTECTED] said: In message [EMAIL PROTECTED], Steve Cohen writes: But what about my point that what we have now is NOT 1.1 compatible? VMSFTPEntryParser broke that, although it could, if necessary, be reimplemented to use Hashtable instead of HashMap. I misread your email (unfortunately an increasingly common experience given the volume of email I have to skim). I thought you said the unit test wasn't 1.1 compatible. Given that the 1.1 release was supposed to be 1.1 compatible, I'm in favor of replacing the HashMap with a Hashtable in a 1.1.1 release and doing a JDK 1.1 build to spot any other compatibility problems. After that, I say we branch the code. Without selectable I/O, we're forced to use inefficient kluges. The guts of the telnet implementation is an abomination, which I wouldn't be too concerned about except that it underpins the FTPClient command conversation. There was some discussion about mandating 1.3, but that met resistance from some. Let alone 1.4. That was a non-starter, as we've already heard from several users here on the other thread. I don't think it's a non-starter. As long as we give advance warning about how the transition is being handled. Say we branch and commit to making bug fixes on the 1.1 tree for x number of month. Since ant is J2SE 1.2 dependent, we ought not move to 1.3 (what do we really gain from 1.3 anyway?). We can plan a series of 1.2 compatible releases for some pre-announced period of time all the while working on a J2SE 1.4 dependent 2.0 release on an experimental code branch. I know it makes maintenance more difficult, but the code is showing its age and not making an attempt to reimplement using java.nio is selling users short in the long run. I'm willing to take the initiative on the experimental or proposal branch. Are there any users of Commons-Net who need 1.1 compatibility? (Remember NetComponents is still available). Available as a courtesy, but unsupported. We'll find out soon enough if anyone still needs JDK 1.1 compatibility if we migrate to 1.2 and announce no new features for 1.1.x releases and only bug fixes for those who request them. To summarize, I now believe the stepping stones should be J2SE 1.2 and then 1.4. J2SE 1.2 compatibility for releases 1.2.x - 1.9.x on the head branch and J2SE 1.4 for release 2.0 on an experimental branch. JDK 1.1 compatibility for 1.1.x releases on a 1.1 maintenance branch. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [net] Branching
I've found that keeping normal development happening on the HEAD branch to be more beneficial than an experimental branch. We would branch for bug fixes only, all new development proceeds on HEAD. If projects start moving to Subversion, which will start happening next year anyway, these sorts of issues would become moot. Not saying that net should switch; just pointing out one of the benefits of Subversion. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: After we make a 1.1 compatible release and tag, that will be the branch point for any 1.1 fixes. Next we can make a release with 1.2 support and tag, that will be the branch point for any 1.2 related fixes. All development then proceeds on HEAD. Its just a suggestion. I can live with an experimental branch also, just in other projects I've been involved with, if HEAD isn't the focal point of new development, it get confusing where to put stuff, what is working, etc. I understand and agree with what you're saying and think we had different ideas of the nature of new development. I was thinking that for the foreseeable future, new development would be focused on enhancing the functionality of the current code, such as Steve's parser factory. I'm proposing we engage in a certain amount of redesign and implementation around java.nio, which may break a lot of stuff and in the end may turn out to be a throwaway experiment to figure out how to implement the next generation of the code the right way. I'm leary of the possibility of going down blind alleys on the HEAD branch. However, I was also going to suggest that the redesign/reimplementation/nio work occur in an org.apache.commons.net2 package (has the advantage of allowing both new and old code to coexist, as may be required in some environments, without playing games with classloaders), which may make it a moot point as we can simply omit that package from releases. At any rate, I don't think any of us are going to embark on any J2SE 1.4 work in the next few days, so let's talk it over some more to figure out where we want to go with this and at least create the 1.1 branch so Steve can continue to make his changes of off HEAD. I'm visiting relatives and have likely not given sufficient thought to my suggestions. All I'm sure of is that we've got three cases to consider: 1. maintenance of a 1.1 compatible product with a schedule to suspend support 2. continued development of a 1.2 compatible product where the next immediately usable features will be developed 3. long term development of a 1.4 dependent product that has a yet to be determined design and may take a year or more to materialize into something usable Steve Cohen, Jeffrey Brekke, and Daniel Savarese all appear to agree on how to do 1, so I think it's safe to skip a vote and just make the branch. Sanity check the steps to make sure this is what we want: o rename NET_1_1_0 tag to something else, let's say FOO o tag FOO as NET_1_1_0, this time with the -b flag to make it a branch tag If that seems like not a good thing, another option is to tag the NET_1_1_0 snapshot with NET_1_1_0_MAINTENANCE or some such tag for the 1.1 maintenance branch and leave the existing NET_1_1_0 tag alone. Having done that then we'll continue new development (e.g., Steve's parser factory) on the HEAD branch until we figure out whether J2SE 1.4 development really belongs on an experimental branch, the HEAD branch, in a net2 package, or some variation thereof. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
I wrote: In message [EMAIL PROTECTED], Jeffrey D. Brekke writes: Its just a suggestion. I can live with an experimental branch also, just in other projects I've been involved with, if HEAD isn't the focal point of new development, it get confusing where to put stuff, what is working, etc. I understand and agree with what you're saying and think we had different ideas of the nature of new development. I was thinking that for the I just realized that my original suggestion didn't make it clear that the experimental branch, should it result in good code, would be remerged into the HEAD branch come time for its first release and the 1.x stuff would branch for maintenance at that point. It may have sounded like I was suggesting that 2.x development continue forever off of a non-HEAD branch. I don't know if that adds anything to the discussion if it was misunderstood. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
I wrote: Sanity check the steps to make sure this is what we want: o rename NET_1_1_0 tag to something else, let's say FOO o tag FOO as NET_1_1_0, this time with the -b flag to make it a branch tag I left out delete the FOO tag ... If that seems like not a good thing, another option is to tag the NET_1_1_0 snapshot with NET_1_1_0_MAINTENANCE or some such tag for the 1.1 maintenance branch and leave the existing NET_1_1_0 tag alone. I forgot to indicate what I favor. Only because I haven't thought of any arguments against it, I favor the first method (change NET_1_1_0 to a 'cvs tag -b' branch tag). The second approach is safer because it doesn't run the risk of screwing up anything and I don't object to it. The only con I can think of to the second approach is that having two tags with NET_1_1_0 in them may be confusing. I don't think I've ever retroactively branched after tagging with CVS (usually, for me at least, branching is premeditated), which is why I don't have a strong preference. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
