* Version 2.0 (JDK 5.0+) becomes the main development branch, and the focal point for new features; * Version 1.x continues to be supported, in that fixes and new features are backported where possible, and code submitted by the community targeted at the 1.x branch can still be applied.
I think this is a pretty reasonable way of moving forward, encouraging new development on a codebase free of the shackles of legacy limitations, whilst still being able to service users with more conservative requirements.
Rory 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.Rory Winston wrote:Hey guysAn interesting discussion here. I'll try to address some of the points raised and give my take on the issue.* As far as [net] specifically is concerned, there are very few things that 1.5 makes possible that you really can't do on 1.3 (One of these is asynchronous I/O and a select()-based thread notification model). However, 1.5 does make a *ton* of things much cleaner. For instance, regex support is now on a par with [oro], so we lose our only external dependency, making [net] a self-contained single jar download. We can also support secure FTP without having to install a separate JSSE jar, as SSL/TLS support is now integral in JCE. Apart from that, there are many, many, smaller enhancements that we can make. Seehttp://people.apache.org/~rwinston/commons-net-2.0/site/changes-report.html#2.0for a few.* As far as I am concerned, the ideal scenario for a project like [net] is that 1.5+ support continues on a different version line. It may be the trunk, it may be a branch. So for [net], the 1.x line is for JDK 1.4.x and below, and the 2.0 line is 1.5+. It doesn't in any way mean that support is suddenly dropped for pre-Tiger releases. But sooner or later, 2.0 is the main development version, and that's where the effort should go.* I don't like the concept of a ".net5" package name. Does this mean that we need a ".net6" package space when JDK 6 is released? It doesn't feel elegant, and it loses one of the big advantages that the current system has : a user can upgrade their JDK from 1.3 to 5.0 overnight, download a new [net] 2.0 jar, and their FTPClient-based code should *just work* (with a 90% probability ;)).* I agree with Henri's comment below about Commons being a "maintenance" vs. "development" space. 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.Cheers Rory Henri Yandell wrote:On 9/9/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote:Steve Cohen wrote: > I am not ready to vote yet on this until there is a discussion about > what this release means. Will commons-net-2.0 become the "official"> release, with previous versions relegated to "backward compatibility"> support? If so, this may be premature as Sun is still supporting > JDK-1.4.2-x. >> But I don't think we should stand in the way of progress either. Rory, > can you comment on what are the specific new features that demand JDK> 5.0 support? > > How have other jakarta-commons projects handled this? Are there any> official versions that require 1.5? Are there projects that have two> "official" releases? I see this as a positive step (a JDK 1.5 only release). I also see this as the right jump (from JDK 1.2/1.3 to 1.5).I'm a strong +1 for JDK 1.5 dependence. The way I see it is that while we're supporting 1.2->1.4, new development happens on 1.5 so the only time we need to worry about older JVMs is for critical bugfixes on maintenance systems - not for new development. Trying to focus on old JVMs makes us a maintenance project, not a development project and that's damaging for the project health. Lang 2.2 is in a limbo state because I can't get 1.2 for my Mac, I need to dig into Ubuntu to try and get it to work there and I can't even figure out how to get it to work on Windows at the moment (JDK 1.6 appears to be taking over the JAVA_HOME and PATH, but it's not defined in the user's environment variables). Another reason is that Lang has tests that fail to pass on 1.2 and 1.3; possibly due to bugs in the JVM (time crap). Even once I can make a 1.2/1.3 build, I'm not sure if I should. Plus other reasons, such as being without a happy laptop at home until tonight :)However, I believe that commons holds an almost unique place in Javadevelopment being the lowest layer in many many open source projects. Assuch making an incompatible major version change is a *very* big deal. [PROPOSAL] As such, I would like to propose that projects creating a JDK1.5 only release should use a new package name. Thus, in this case, the release would use the package org.apache.commons.net5.*.-1 for a slew of reasons. * Lots of source code would have to be touched just to upgrade; big pain in the arse for something that is quite likely to not involve any other change to a user's source. * Building v49 class files is going to explode on a v48 JVM, so people are going to be stopped pretty quickly from using the net5 on their old JVM. We don't need to protect them via packages. * Do we do net3 and net4 if we move from 1.2 to 1.3/1.4? Do we do net6?With this change, a user can have both the old and the new commons-net jars in their classpath without any conflicts.Only a JDK 1.5 user (1.6 too I guess). Presuming we make 1.5 targetted builds and not 1.2->1.4. And then it's nothing to do with 1.4/1.5 and just the classic problem of package clash within dependencies.Note that these users may be different OSS projects, which may upgrade at different times.Users wishing to migrate from one version to another can simply do a global search and replace on the package name.We must not underestimate the significance of the low-level position ofcommons in the Java OSS, and proprietry, communities. A clear and planned migration strategy for all our modules is needed.I accept that by its nature Commons is going to cause problems every time they release. We're going to be a frequent location for classpath clash problems. It's not JVM relevant though, it happens every time we release anything so the version you would need in the package name is the Commons major version, not the jdk version. I think we should declare that new development will be on 1.5 - building 1.5 only jars. Anyone trying to use them on 1.4 and before is going to get a nice error and we can start exploring new JDK features like regular expressions *sarc :) *. Then we can stick with it until 1.8 is in beta or something. Hen --------------------------------------------------------------------- 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]--------------------------------------------------------------------- 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]
