In the IRC today we decided that we should release on the 1st of each month, more of a 'milestone' than a full on beta release. Right now the release process rests in James's hands, and he can get quite busy. We should make the process easy enough that any of the PMC can cut a release. This does not necessarily mean automation of everything - I personally think that's overkill, and would probably delay this release. What I'd like to see is enough automation to build the jars and zips - a 'maven release', which takes the name of the release 'B2' or M2 or whatever, and creates all the appropriate files. GeoServer has an ant task that does a similar thing (though yes, it is easier with geoserver). Beyond that I think we just need a section in the Developer's Guide that is a 'howto' on releasing. What to upload where (zips to sf, link to their file release system, javadocs to shell.sf.net?, individual jars to ibiblio (james, can other pmc members get ibiblio access? At least a few, so it doesn't all rest in your hands?), and how to announce the release. I can volunteer to write part of that document. Once this is in place we should be able to just cut a release on the first of each month, so that people can track our progress. Hopefully the thought that something will be coming out soon will spur developers to get stuff done.
This also means that groundbreaking developer work should move to branches more, since if everything does not build on the 1st then we can't really release.
CodeHaus Comment From: cholmes - Time: Mon, 16 Feb 2004 17:18:03 -0600
Logs about issues from gt2 irc Feb. 16 2004: (sorry for bad formatting).
jgarnett Chris did you make on progress on a release timeline?
jgarnett I loved you email on the subject
cholmes You mean release for geotools? No, I didn't make any progress on the timeline. James was going to look into making releases easier.
aaime Mee too
Martin_ I can take care of Javadoc generation. I'm getting used to that
Martin_ (I mean a single Javadoc for the whole Geotools)
aaime I've got a script for this too
cholmes So when do we want to aim for a release?
jgarnett A single java doc would be great, it woudl be very nice to link to from other projects like GeoServer.
cholmes Do we have anything that absolutely has to be done?
aaime Legend legend legend
cholmes Are you planning on working on it in the next week or two?
jgarnett I would like to attack the problem from another direction, we have our release guidelines (60% coverage tests and so on), it would be nice to cut a release on the 1st of every month. If you make the 60% cut your module can be in the release
jgarnett Any month that something like data does not make 60%, the project as a whole cannot make a release
Martin_ Maybe we should call our release just "Milestone". So it is not really a beta release. Release need the 60% coverage tests; Milestones would not be that strict.
cholmes That would be fine with me.
jgarnett That makes sense.
aaime Sounds nice. We should also start to use more branches for more ground breaking changes
jgarnett It seems we are all in volient agreement
cholmes So to get a march 1st release what do we actually need? We'll need martin to make up the javadocs, and then we need James to create the downloads.
cholmes It would be nice if we didn't have to depend on James, as he tends to get a bit swamped.
jgarnett I should have DataStore coverage tests, but I can skip that for a milestone
cholmes So I think by march 1st we need good automatic release scripts.
jgarnett How are releases usually made? One big jar?
cholmes One to make the jars, one for the source? And then we also have to upload to the maven space and perhaps change the release?
cholmes Well 'usually' is not really a term we have in geotools
Martin_ I would vote for 1 big JAR.
cholmes But James did put out I think one big jar, and then also a more distributed version, like a few weeks ago.
aaime Me not. Why would I need ArcSDE built in if we don't use it? The whole jars are more than 2 MB...
cholmes So he's done it at least once, I'm just not sure if he automated it.
jgarnett I know for geoserver Chris makes one big jar, and then individual jars for each DataStore
IanS I like one big jar with datasources on the side
Martin_ I would like modules to be the same (one big core module with datastore as separated modules).
jgarnett Once again it seems we all agree?
dzwiers I support smaller jars
aaime Seems so. Do we want lite and j2d in the same package?
cholmes Yep, I agree (though that's a bit obvious as I do it for geoserver)
jgarnett Did we want to separate out some of the hight level modules like graph and validation?
dzwiers then individual projects can link and distribute the portions they need
dzwiers was almost thinking 1jar = 1 module
dzwiers maybe a grouping for core
dzwiers just some ideas
iant could we do both?
cholmes ...Actually, if people want individual jars for each module then they can download them from the ibiblio site.
cholmes So we can point people in that direction for individual stuff, and make the released one with a centralized jar and individual datastores.
cholmes I wouldn't be against putting a few high level ones in seperate jars for the more centralized release though.
dzwiers but should the creation and uploading of these jars be part of the release process (or am i missing something here)
dzwiers *should not
dzwiers iant: don't see why not
cholmes huh? Part of the release will be uploading new jars to the ibiblio space, yes.
dzwiers ok, then i think we agree
jgarnett dzwiers: I think we are trying to avoid having a bunch of small jars (since many cannot be used on their own, and we have so many of them)
aaime Is there any way to get a dependency graph?
dzwiers mmm, 6 of one, 1/2 dozen of the other ...
cholmes Ok, so I'd say the one big task before March 1st is to make it easy enough that any of us could cut a release, with some nice automatic scripts combined with some nice docs on how to do it.
Martin_ I like the idea of one big jar for release, and pointing peoples to ibilio for small jars.
Martin_ Where to we put the scripts?
aaime Oh, what about the legend and gui modules? How we are supposed to unit test them? jfcunit?
dzwiers personally i would never use a big jar if I had options ... use ant to build smaller ones atm
dzwiers (still like set of small ones, dependency graph is also a good idea)
aaime For servers side tasks I'd say it does not matter much, and for applets some kind of shrinker should be used anyway... but a big jar is going to create troubles to the shrinker too
Martin_ J2SE 1.5 has a new compression scheme for JAR
Martin_ It is supposed to be better than the old JAR compression, especially for big JAR
aaime I know. But it's another 8 MB download for users...
Martin_ (the current compression scheme has a lot of redundancies, e.g. "java.lang.String" string which appears in the constant pool of about all classes)
Martin_ Yes Andrea, I agree. I just believe that we should offers both options and lets user choose.
Martin_ My question would be: is it acceptable to just point user to ibiblio for small jars?
iant if they are using multiple jars then they can probably work maven too
dzwiers martin: i would say no
dzwiers java 1.5 jar: did the list not agree not to use java 1.5 code? then why would we use the jar?
cholmes I think it's acceptable to point users to ibiblio, just have a nice readme in the sourceforge jar download that points nicely to it with the dependancy tree.
dzwiers but either way we can just show it out there, and then revise for the following release
cholmes The alternative is to have geotools-b2-big-jar.zio and geotools-b2-little-jars.zip
cholmes Which I would find a bit confusing as a user...
jgarnett Hmm, we can always ask the list/ our users what they would like
aaime Not if we state clearly what is the purpose of the double packaging.
dzwiers other question, will we distribute something like
IanS lets make them all .exe
aaime .zip, always, tar.gz is a bit more troublesome on Windows
TheSteveMonkey tar.gz is stinky on windows
dzwiers winzip can deal with .tar.gz
TheSteveMonkey zip or jar works
cholmes is what we currently have.
dzwiers works here, I would just split into a few libs (core, datastores, graph, GUI, validation ...)
jgarnett We seem to be running in circles here, One option here is to decide on something, and ask for feedback based on march 1st
<-- ThangLai has left irc.us.freenode.net ("ChatZilla 0.9.52B [Mozilla rv:1.6/20040124]"
jgarnett Okay I will propose the milestone on the 1st idea to begin with...
jgarnett Do people think this is a good idea?
aaime +1 for me
jgarnett +1 for me
cholmes I propose one big jar for download, and pointing to ibiblio for individual jars, to get us started, and then ask for feedback.
cholmes (I think this is how we already do it, so it's easier to set up)
jgarnett that is is plenty to get started on
cholmes And should we formalize the process for which modules get in a milestone release?
aaime We should also decide on the 60% coverage limit, getting at 80% was difficult last time
cholmes +1 on 60% minimum, with 80% recommended.
jgarnett I was very new last time, can someone run over what the group learned last time?
jgarnett We may want 60% for milestone, 80% for the 2.0 release)
jgarnett Reset: I did not know that 80% was hard, is there any other leasons we learned last release?
iant mostly that programmers are lazy and don't like docs
Martin_ Missing time I think...
cholmes Yeah, I think the lesson is that if we hinge everything on people getting stuff done we'll be waiting a long time. We should just release with what we've got, get it out there.
jgarnett Okay, this is all good feedback. Did we get any feedback from users?
cholmes For the most part they didn't really know about the release.
cholmes We also only released source last time.
cholmes Which was silly because they then had to get maven anyways.
aaime Users complain for a lack of tutorials
CodeHaus Comment From: jmacgill - Time: Fri, 19 Mar 2004 11:20:52 -0600
OK, the bulk of this has now been done. I'm sure there will be some improvments over time but I think it meets the criterea of 'any developer' being able to use it.
Details on the release process can be found at: