This is a list of books currently on my To Read shelf... literally. I do not suggest or anti-suggest any of them at this time as I haven't read them yet.
Current Efforts:
Blue Parabola, LLC
HubAustin
web2Project
PHP'ers:
Cal Evans
Eli White
Elizabeth Naramore
Joe LeBlanc
Matthew Turland
Matthew Weier O'Phinney
Planet PHP
Tony Bibbs
Business/mISV:
Bob Walsh
Eric Sink
Joel Spolsky
Micah Baldwin
Paul Graham
Past Projects:
CodeSnipers
HOBY
Judicial Watch
mobile FoxNews.com
NRTW
Great Tools I use:
Drupal
GitHub
NetBeans for PHP
phpUnit
Subversion
Zend Framework
This is not the home of dotProject or web2project. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
In my regular web wanderings this morning, I found something interesting. A company that I'm familiar with just released v3.0 of their primary product. At first glance, I was happy for them, then I remembered something odd, they released v1.0 early this year. By all standards, going from v1.0 to v3.0 in under a year is aggressive... so I started to dig and found something interesting:
V1.0 was released in February...
v2.0 was released in July...
v3.0 was released in December...
with no point releases in between.
Wha?
That's right, they had three major releases in a 10 month span with no minor releases in the interim... which poses an interesting question about using their system:
What is compatible with what?
As software versioning notes, a version number normally consists of three parts:
Major.Minor.Build.Release
Release - The Release (optional) is unique to each and every release. This can just be a sequential id for each release but is more often a Subversion Revision number (always increasing). That makes it easy to track that release back to a specific state of the code.
Build - The Build is normally a simple counter that increments until the next Minor release. This is used to denote bug fixes and potentially optimizations. You can see this on the PHP5.2 line. We have version 5.2[.0] (zeros are often left off), 5.2.1, 5.2.2, and we're on 5.2.8 preparing for 5.3[.0] right now. More importantly, backwards compatibility is maintained. Anything that works on 5.2.1 should work equally well on 5.2.4 or 5.2.8.
Minor - The Minor version is works similarly but not quite the same. It's normally a simple counter but instead of just fixing bugs, it adds new functionality. You can once again see this on the PHP5 line. We have the upcoming 5.3 release that includes all kinds of nifty new things like closures, lambdas, PHAR, Namespaces, and all kinds of nifty bits. The downside of getting new features is that sometimes things break. Backwards compatibility is strongly encouraged and worked towards but not guaranteed.
Major - Releases of Major versions are a whole other story. Not only are there bug fixes and new features, but there could be whole new re-workings of the core system and any backwards compatibility is an unexpected feature, not a guarantee. The PH4/5 conversionis one example, but the Office 2000/20003 to Office 2007 conversion is an even clearer. Files created with Office 2007 aren't backwards compatible with Office 2003.
Now let's get back on point...
When an organization - commercial or otherwise - skips over Build/Minor releases and sticks to Major releases, they may think they're showing how stable and active their community is... but they're actually doing the opposite:
They're creating a community that has to question whether their modifications and extensions.
They're creating a community that is always playing catch up in terms of documentation and understanding.
They're not giving any guidance for future versions and slowly stepping into them, they're simply rushing ahead full steam.
And most disturbingly, their users can't have confidence that their data will convert across and work without issue.
Post new comment