+1 from me to start releasing the next version as 1.0. Taking a look at the current algorithm used by Maven for comparing versions [1], and at the Versioning page [2], I don't see any problem.
Piergiorgio [1] - http://maven.apache.org/ref/3.0.4/maven-artifact/xref/org/apache/maven/artifact/versioning/DefaultArtifactVersion.html [2] - http://docs.codehaus.org/display/MAVEN/Versioning 2012/9/13 Karl Wright <[email protected]> > The more I think about this, the more I think we may well be able to > segregate ManifoldCF into "major releases" over time. Some of the > very large tickets (for example, multi-server crawling) will almost > certainly have a big impact on practically everything ManifoldCF does. > I propose, then, that our major releases coincide with these very > significant framework changes. > > That would imply that we can continue to have 0.xxx releases for quite > some time, but since we did not plan on such an arrangement in > advance, and since we want tools like Maven to work with our version > numbers, I propose that we begin the 1.xxx series of releases right > now, in this current release. Furthermore, we would include a minor > level for patch releases in each version number. For example: > > 1.0.0 - release on Sept 30 > 1.1.0 - release on December 31 > etc. > > The only question I have is what will Maven's version comparison logic > do when it sees a version like this: > > 1.17.0 > > Hopefully it will recognize that this is a higher version than 1.2.0? > Mavenistas, what say you? If Maven doesn't work right with this, we'd > want to reserve digits in advance, e.g. > > 1.000.0 > 1.001.0 > > > Karl > > > On Wed, Sep 5, 2012 at 2:07 PM, Karl Wright <[email protected]> wrote: > > I don't think there are any hard rules about what constitutes a 1.0 > > release, except perhaps some subjective measure of completeness, and > > some measure of backwards compatibility support. For example, Lucene > > insures that every major release number (3.x, 4.x) are > > index-compatible. > > > > I don't know what the equivalent major release equivalent would be for > > ManifoldCF. We have a mature database schema which self-upgrades, so > > that is not going to work in the same way as Lucene indexes. We > > *could* just keep counting: 0.7, 0.8. 0.9, 0.10, 0.11 etc. But that > > gets cumbersome too. > > > > Karl > > > > On Wed, Sep 5, 2012 at 5:44 AM, Piergiorgio Lucidi > > <[email protected]> wrote: > >> Taking a look at all the recent fixes, I think that we could release a > new > >> version of ManifoldCF because there are many improvements: > >> > >> > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CONNECTORS+AND+fixVersion+%3D+%22ManifoldCF+0.7%22+AND+status+%3D+Resolved+ORDER+BY+priority+DESC&mode=hide > >> > >> I don't know what rules are defined for calling it as "1.0", but in the > >> meanwhile we could release a 0.7 version. > >> Personally I think that this new release could be named 1.0, but this > is my > >> feeling :) > >> > >> Piergiorgio > >> > >> > >> 2012/8/27 Karl Wright <[email protected]> > >> > >>> Hi Folks, > >>> > >>> It's already time to start winding down the 0.7 release. > >>> > >>> Before this is done, I think we need the following: > >>> > >>> (1) Voting on the current outstanding SharePoint-2007 plugin release. > >>> Still need 2 votes. > >>> (2) Completion of, and voting on the new SharePoint-2010 plugin > release. > >>> (3) Completion of all outstanding tickets marked "Fix in ManifoldCF > 0.7". > >>> > >>> I'd also like to explore what the criteria should be for calling a > >>> release "1.0". It seems to me that Jukka and others might have an > >>> idea of when this would be appropriate. Does anyone have any thoughts > >>> on this matter? > >>> > >>> Thanks, > >>> Karl > >>> > >>> -- > >>> Piergiorgio Lucidi > >>> http://www.open4dev.com > >>> > >>> > -- Piergiorgio Lucidi http://www.open4dev.com
