[Qgis-developer] Re: QGIS 1.0.3 is next...

[Tim Sutton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi


Alex Mandel wrote:
> I was under the impression that the next unstable release would be 1.2
> aka bugfixes for unstable are always in the trunk. While 1.0.3 is the
> next stable as those bugfixes when possible are simply applied to the
> stable version.
> 
> In fact the 1.1 branch is only a branch for packaging reasons.
> 
> Then again this is my thinking from an outside view,
> Alex
> 
> William Kyngesburye wrote:
>> So, just to clarify the plan, future releases of 1.1 unstable will have
>> revision version numbers?  ie 1.1.1, 1.1.2,...

No as Alex mentioned the will be 1.x > 0.x  releases.

>>
>> And the next stable version would be 1.2?

We will aim for 2.0 to be the next stable release in a year or so time,
at which point we will discontinue maintenance of 1.0.x and support
2.0.x for a longer period of time.

>>
>> Are you defining some alternating stable/dev version number system, like
>> GRASS does?  ie major.even = stable, major.odd = dev.
>>

Before 1.0 release we used to have a somewhat arbitrary numbering
scheme. In answer to requests from debian folks and others we switched
to the major.minor.bugfix numbering scheme:

"In principle, in subsequent releases, the major number is increased
when there are significant jumps in functionality, the minor number is
incremented when only minor features or significant fixes have been
added, and the revision number is incremented when minor bugs are fixed.
A typical product might use the numbers 0.9 (for beta software), 0.9.1,
0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 2.0, 2.0.1, 2.0.2, 2.1,
2.1.1, 2.1.2, 2.2, etc. Developers have at times jumped (for example)
from version 5.0 to 5.5 to indicate that significant features have been
added, but not enough to warrant incrementing the major version number,
though this is improper."

(from http://en.wikipedia.org/wiki/Software_versioning)


The intention is that 1.x releases will remain API (but not ABI)
backwards compatible and that 2.0 will be API breaking.

I think its better to treat all 1.x >0 releases as unstable and just
maintain 1.0.x until 2.0 comes out. Many people I am dealing with are
building training materials etc that rely on the GUI remaining the same
- - they are less interested in new features than they are having
something with consistent appearance and functionality. I know for us
developers 1.0 already seems like old news, but when you are building
training materials around the application its much easier if the UI
doesn't change every few months event if the feature set doesnt grow as
quickly.


Best regards

Tim



- --

Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.

Visit http://linfiniti.com to find out about:
 * QGIS programming and support services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==============================================

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoOa30ACgkQqk07qZdiYjcowACeNpcUFtwUzxQhbmlQamrkxGL6
hF4AnjwotWIKjWWI2oYggN4l3agpL94i
=rzi0
-----END PGP SIGNATURE-----