> Hi Jody, > trying to understand your proposal, which at a firs read looks like it > would break time boxing and predictability. >
Should remain predictable. Examples: if GeoNode rolls a 2.7.3 release in September, whatever date, > will we still release a 2.7.4 in October (when 2.7.3 was actually scheduled > for)? > Correct. The release dates are fixed, if a "bonus" release shows up due to a volunteer having need so be it. I would reserve a patch release for when a previous release is used as the starting point for a branch (as was done for recent security releases). What if a sibling project needs a release 15 days before the official > relase date (say GeoNode's 2.7.3 would be at the end of September), would we > still release the regular release 15 days later? Maybe with just one or > two changes (not entirely unlikely on a maintenace series, which is what > 2.7.x will become September 18th when 2.8.0 becomes the new stable?) > That is correct. Release date is predictable (in part because we have made this time boxed commitment). This does not preclude volunteers from stepping up to make additional releases. Indeed I would much rather see "downstream" projects make a versioned GeoTools release than latch on to a specific snapshot revision. -- Jody
------------------------------------------------------------------------------
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
