[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Version number of next release

+1.  Agree.  Too many changes to be a point release


On Mon, Dec 20, 2010 at 4:31 AM, Glyn Normington <gnormington@xxxxxxxxxx> wrote:
Master is currently versioned at 2.2.0.x but I think there is already a case for making the next release 3.0.

The switch to Equinox 3.7 introduced generics into the OSGi API and made other changes destined for OSGi 4.3. With the generics change alone, applications that reference the API may need reworking to compile and, even if they do compile without change, will probably need reworking to compile without warnings. This was quite disruptive in the kernel and I imagine it will be disruptive to large OSGi applications. However, I believe the changes are binary backward compatible, so Equinox 3.7 alone might not be quite sufficient to warrant a major version change.

But then the framework hooks change is also looking fairly disruptive as the user region is no longer in its own nested framework. This will affect applications which trace wirings, e.g. using Package Admin, because they will now see kernel bundles instead of seeing wires to kernel region bundles terminating at the surrogate bundle. This change also affects configuration - for example there is now only one set of framework properties so console support is impacted and there is no longer any concept of inheriting framework properties from the kernel to the user region (or if you prefer, all framework properties are inherited unconditionally).

Furthermore if some of the items we discussed at the Virgo F2F are implemented, there will be even more reason to version the next release at 3.0, for example file system layout changes would impact any user scripts which access Virgo's directories and the (possibly binary backward compatible but nevertheless signficant) Tomcat 7/servlet 3.0 support.

Unless anyone has strong objections, I will raise a bug to reversion master to 3.0.0.x in which case we should probably implement that before the next milestone (3.0.0.M01 instead of 2.2.0.M02).



virgo-dev mailing list