Re: The case for version number inflation - Mailing list pgsql-advocacy
From | Susanne Ebrecht |
---|---|
Subject | Re: The case for version number inflation |
Date | |
Msg-id | 515AB3EE.6060207@2ndquadrant.com Whole thread Raw |
In response to | The case for version number inflation (Josh Berkus <josh@agliodbs.com>) |
List | pgsql-advocacy |
Hello Josh and others, Am 27.02.2013 23:55, schrieb Josh Berkus: > > I'm beginning to think that no matter how much *I* like our version > numbering scheme, it's hurting us with users because they see the last > three releases as "version 9". One of PostgreSQL's best features is > that we do a new major release every year, meaning that the database is > improving greatly every year. To the vast majority of the population, > our version numbering scheme doesn't tell that story. > Also IOS is using "our" kind of version numbers. There are lots of companies outside where changing a tool version is more efford to prepare then preparing a visit from British Queen. Even changing the minor release number isn't possible without having QA testing it for 6 months and lots of bureau-crazy form getting approval from the biggest boss. Especially in ISO 9000 family certificated companies updating a tool is a huge effort. My information is that that is one of the reasons why RedHat still use such an old kernel version. Last year the German community found a PostgreSQL 7.4 in a device. It is pretty clear why this happened - 7.4 was the actual release when the company started to develop the device - the device has had minimum 5-years testing phase before it get onto the market. Two years development, 5 years testing, let's say 1 year more development because of negative tests and the device came out two years ago - that makes 10 years - so it isn't suprising that 10 years old software is used. 5-years testing is pretty normal for white ware devices (devices used in household). I missed the point - I like our versioning system. I also like to explain it. And I like that we are so strict here. Version x.y.z - when we change z then you can be sure it are really just bug and security fixes. When we change y then you have a few new feature but we are still backward compatible. When we change x then we changed architecture and maybe we aren't backward compatible. In ISO 9000 family cert companies you can say that version x.y is used instead of x.y.z You usually need to point out the exact version and you aren't allowed to change it. I already discussed a lot that companies should update when .z changed - but - you know ... I like to explain again and again and again - to recommend again and again and again to these companies that when you use PostgreSQL you can place version x.y in your documents instead of version x.y.z. Of course it is still risky and violates ISO 9000 family because we don't guarantee that we never will place new features or architecture changes in a .z-update. When you just say version 10, 11, 12, 13 - you don't know if it just was new feature of architecture changes. Will replication break because architecture xlog changed or not? As I said at the beginning - Apple seems to use x.y.z too. And here in Germany you will find more and more Apple users. Iphone, Mac, Ipad ... Just my 2ct, Susanne -- Dipl. Inf. Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com
pgsql-advocacy by date: