Hi all,
today we stuck a bug, scheduled for fixing in 1.4.0rc2, that
needs a geotools change.
It's quite evident that requiring a geotools release for each
geoserver milestone or RC simply does not work, we almost had
to re-release 2.2.1 two days later, and now we would need another
one. This is clearly unacceptable, given the effort required
to release geotools (at least half a day).
The only viable alternative is, according to me, to depend on snapshots for milestones and RCs, and release geotools only for geoserver final releases.
Gabriel
On Thursday 26 October 2006 16:07, Andrea Aime wrote:
Hi all,
today we stuck a bug, scheduled for fixing in 1.4.0rc2, that
needs a geotools change.
It's quite evident that requiring a geotools release for each
geoserver milestone or RC simply does not work, we almost had
to re-release 2.2.1 two days later, and now we would need another
one. This is clearly unacceptable, given the effort required
to release geotools (at least half a day).
The only viable alternative is, according to me, to depend on snapshots
for milestones and RCs, and release geotools only for geoserver final
releases.
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
+1 here. Perhaps we could say something like the first Release Candidate should have a GeoTools release, or at least something to encourage GeoTools releases. But we can't go through that whole process for every minor fix.
Chris
Gabriel Roldán wrote:
sounds completely reasonable to me.
+1
Gabriel
On Thursday 26 October 2006 16:07, Andrea Aime wrote:
Hi all,
today we stuck a bug, scheduled for fixing in 1.4.0rc2, that
needs a geotools change.
It's quite evident that requiring a geotools release for each
geoserver milestone or RC simply does not work, we almost had
to re-release 2.2.1 two days later, and now we would need another
one. This is clearly unacceptable, given the effort required
to release geotools (at least half a day).
The only viable alternative is, according to me, to depend on snapshots
for milestones and RCs, and release geotools only for geoserver final
releases.
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
+1 here. Perhaps we could say something like the first Release Candidate should have a GeoTools release, or at least something to encourage GeoTools releases. But we can't go through that whole process for every minor fix.
Chris
Gabriel Roldán wrote:
sounds completely reasonable to me.
+1
Gabriel
On Thursday 26 October 2006 16:07, Andrea Aime wrote:
Hi all,
today we stuck a bug, scheduled for fixing in 1.4.0rc2, that
needs a geotools change.
It's quite evident that requiring a geotools release for each
geoserver milestone or RC simply does not work, we almost had
to re-release 2.2.1 two days later, and now we would need another
one. This is clearly unacceptable, given the effort required
to release geotools (at least half a day).
The only viable alternative is, according to me, to depend on snapshots
for milestones and RCs, and release geotools only for geoserver final
releases.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
------------------------------------------------------------------------
I'd suggest that we ought to however _aim_ for a geotools release for each major milestone, but not for subsequent maintenance releases. I think the release process will focus the minds on the quality of the build a little better, and Geoserver releases against it should be seen as part of the testing process for getting Geotools through the release cycle.
Rob A
Gabriel Roldán wrote:
sounds completely reasonable to me.
+1
Gabriel
On Thursday 26 October 2006 16:07, Andrea Aime wrote:
Hi all,
today we stuck a bug, scheduled for fixing in 1.4.0rc2, that
needs a geotools change.
It's quite evident that requiring a geotools release for each
geoserver milestone or RC simply does not work, we almost had
to re-release 2.2.1 two days later, and now we would need another
one. This is clearly unacceptable, given the effort required
to release geotools (at least half a day).
The only viable alternative is, according to me, to depend on snapshots
for milestones and RCs, and release geotools only for geoserver final
releases.
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
That can work Andrea, and is a good suggestion - I believe there is a mechanism for publishing snapshots to the repository? If we can document that process it would be good.
Jody
Hi all,
today we stuck a bug, scheduled for fixing in 1.4.0rc2, that
needs a geotools change.
It's quite evident that requiring a geotools release for each
geoserver milestone or RC simply does not work, we almost had
to re-release 2.2.1 two days later, and now we would need another
one. This is clearly unacceptable, given the effort required
to release geotools (at least half a day).
The only viable alternative is, according to me, to depend on snapshots for milestones and RCs, and release geotools only for geoserver final releases.
Cheers
Andrea
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
That can work Andrea, and is a good suggestion - I believe there is a mechanism for publishing snapshots to the repository? If we can document that process it would be good.
As far as I know there's something already publishing geotools
snapshots from 2.2.x branch on lists.refractions.net.
Don't know if it's a CruiseControl tool at Refractions, of
it's maybe a JesseControl, RichardControl or a CoryControl... :-p
I'd suggest that we ought to however _aim_ for a geotools release for each major milestone, but not for subsequent maintenance releases. I think the release process will focus the minds on the quality of the build a little better, and Geoserver releases against it should be seen as part of the testing process for getting Geotools through the release cycle.
Hmm... can you define major milestone?
Thinking about it, it seems reasonable to require that each geoserver
milestone/release candidate works against a geotools "stable" branch
(2.2.x, 2.3.x) as opposed to trunk, and that we push a real geotools
release for every geoserver "stable" release (so, not milestone nor RC).
And yes, indeed this means that we need a cruise control that pushes
that branch snapshots onto the maven repos.