[net] Branching

["Jeffrey D. Brekke" <jb...@wi.rr.com>]

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" <df...@savarese.org> said:

> In message <20...@comcast.net>, 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

-- 
=====================================================================
Jeffrey D. Brekke                                   jbrekke@wi.rr.com
Wisconsin,  USA                                     brekke@apache.org
                                                    ekkerbj@yahoo.com


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [net] Branching

["Noel J. Bergman" <no...@devtech.com>]

> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org