commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [PROPOSAL] Commons and JDK5, was VOTE Release [net] version 2.0
Date Sun, 10 Sep 2006 16:54:20 GMT
On 9/10/06, Steve Cohen <> wrote:
> Continuing the discussion:
> 1.  Regex support is in 1.4.  It's only because we were trying to stay 1.2/1.3
> compatible that we couldn't use it.  That's a small point.  I doubt we want to
> have (say) a 1.4.2 branch that requires 1.4 after having supported 1.2/1.3 for
> all these years, if our soon-to-be target is 1.5.  I do agree that the oro
> dependency has been a very annoying pebble in the shoe.
> 2.  I'm not comfortable with the .net5 package name.  I see a cvs nightmare down
> that road.  I guess SVN can handle that but it's still ugly.  It makes upgrade
> for clients of net a maintenance nightmare.
> 3.  > JDK 5.0 has been officially released for around
>  > two years. In my opinion, there shouldn't even be a debate. It should be
>  > taken advantage of, and supported, although not at the expense of
>  > existing users on older versions.
> No, there unfortunately does need to be this debate.  Sun has not end-of-lifed
> 1.4.2.  That is important.  They continue to release new subreleases of 1.4.2.
> Why?  Important clients are still not ready to use 5.0.  My employer, a very
> large corporation, now mandates the use of 5.0 but is forced immediately to
> relent on this mandate for some of its most important projects because it also
> still uses a lot of Websphere which still does not support 5.0 (and won't until
> WebSphere 7 is released and even then it will be some time before the server
> teams are ready to make that switch - they dragged their feet on Websphere 6
> until recently).  So Sun has to support 1.4 (and continues to have to make new
> subreleases of 1.4.2 for reasons such as the new daylight savings time start/end
> dates).  The world marches on even when corporate java clients do not.
> Backward compatibility's a bitch, but if Sun has to worry about this, I think we
> do too.  I don't think jakarta-commons has ever "downgraded" a version of java
> that Sun considers live.
> And yet, as Rory says, there are some compelling reasons to do so. I'd love to
> use JDK 5.0.  It hasn't been a possibility for me yet.  Even outside of work,
> for a long time Eclipse did not support 5.0 although I don't think it is anymore.
> So what is the solution?  What does it mean to say "not at the expense of
> existing users on older versions?" I think we'd need to modify the site to have
> full support for two release branches, with some easy switch between them.
> There should be navigation menu items on the 2.0 site that point back to the
> 1.4.x site and vice versa as is the case with Tomcat and other projects.  We
> can't just say all new development will be on 2.0, we'll continue to make 1.4.1
> available for those who can't make the move.  We may want to say that, but I
> don't think our user base will let us.  Until Sun EOL's 1.4.x, I think our
> policy must be that every change that can be supported on pre-2.0 will be
> supported there.
> I also wonder if this should be a jakarta-commons-wide policy and not just
> something that net does.

Mostly agree to Steve's note above. IMO:

 * New projects have a choice to start off with 1.4 (the least version
that hasn't begun the EOL process) -- as did SCXML. Unless ofcourse,
the central concept of the component itself is based on a 1.5 (or
higher) feature.

 * Older projects need to atleast support 1.4 (with active development
as in ports back from a 1.5 branch where possible etc.) until 1.4
begins to be EOL'ed. Again, above caveat will apply.

Having said that, I've been a proponent of 1.5 branches (and now
releases, as long as they're preceded by suitable discussion).

As a sidebar, Hen -- I feel your pain about having to go <=1.2 for
certain releases. Personally, I won't even think about RM'ing anything
that needs those. In the end, if its causing much grief that hampers
releases, perhaps that baseline may need revisiting.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message