11 ms·

You can have a fast internal development cycle without devaluing the established concept of major version numbers. I don't appreciate this because I make money

by Padraig 16y ago

You can have a fast internal development cycle without devaluing the established concept of major version numbers. I don't appreciate this because I make money from software. To me, a new major version number is: a) an indication that there have been major changes. It's not something that increments every 12 weeks. b) something most people reasonably expect to pay for. I know Mozilla isn't first with this approach. It still sucks. Edit: Interesting that it has been driven by the same company that rendered the term 'beta' meaningless. Edit 2: Why the downvotes?

Silhouette 16y ago
I don't mind faster releases if they're doing things we traditionally associated with minor version numbers, such as performance improvements or slightly UI tweaks. I really hope they don't change any rendering components at the same pace, though. I already have to strike any contractual obligation to test/support Chrome in commercial web development projects, because it's a moving target and Google do release breaking changes. If Mozilla browsers go the same way, then I really will start coding for the nice, stable, standards-friendly world of IE -- and that's never a statement I thought I would write on a serious forum with a straight face!
- bzbarsky 16y ago
  The plan is most certainly to make Gecko updates on a 3-month cycle. That means new features, bugfixes, etc.
- nitrogen 16y ago
  Can you give some examples of HTML/CSS-compliant layouts or layout features that were broken by changes in Chrome or Firefox?
  - Silhouette 16y ago
    Please see my other post: http://news.ycombinator.com/item?id=2189846 http://news.ycombinator.com/item?id=2189846
  - alanh 16y ago
    H.264 is scheduled to be broken in Chrome in exactly 6 weeks (given Chrome 9 came out this week)
  - thristian 16y ago
    Recently I worked on a website with a lot of forms, and decided to use HTML5 form validation to make my life easier, with a JS fallback for older browsers. It turns out that Webkit added support for HTML5 form validation, then found a problem, so they switched off the implementation without switching off the exposed API. So every JS fallback that tests for the presence of the HTML5 methods on form elements will assume that HTML5 form validation is implemented, and leave the validation up to the browser... which doesn't actually do it at all. That means server-side validation, which of course one needs to do anyway. But it's not to hard to imagine somebody making a site during the brief window when Chrome supported HTML5 form validation, and then discovering their site broken in Chrome a few months later.
    - ahrjay 16y ago
      They didn't "switch it off" they merely turned off form submission blocking when the form was invalid. It's back on in chrome now because they have the error notification bubble. The constraint validition API, the error pseudo-classes and the extra attributes all work in Safari.
      - thristian 16y ago
        If the answer to "are the contents of this form valid" is always "yes", I don't really care how much of the validation API the browser supports; it's effectively going to waste. I'm glad to hear it's turned back on; I hope the form-validation interface is as sleek and professional-looking as the one in Firefox 4.
tomkarlo 16y ago
Arguably, the concept that ties major releases with major purchases is old and broken. It discourages companies from making major updates to software between such releases, as it will actually make it harder for them to make new revenue off the next major release. So you get point releases that are mostly minor bug fixes, and then a huge release every year or two that the maker hopes will squeeze you into opening your wallet, even if you're mostly happy with the last release. Web apps are clearly going to break this version treadmill. Even if you're downloading a package to the desktop, modeling software more as a service - you pay for the right to use software for a period including all updates, rather than for a perpetual license that in reality will expire and need to be re-purchased as soon as the next major version hits. Pay as you go is better for both users and developers. It means you can charge less up front, spend less on marketing (since the cost of trialing the software drops) and focus on delivering the _best_ experience to all your users rather than denying some features to existing customers in order to create a future revenue event.
- Padraig 16y ago
  Sounds great but I am never going to pay a subscription for my IDE, or my FTP program or my Twitter client. Relationships require trust and effort from both parties and it's simply not a perfect model for every piece of software. I don't want a relationship with a company. For most apps I want to buy and own a thing as it is now. This "old and broken" model persists because it's something that customers get instantly and can commit to knowing in advance what their full investment will be.
  - skybrian 16y ago
    With Android apps (and iPhone I presume), it seems that you pay once and automatically get any available updates. I'd guess that would work reasonably well for small utilities, so long as they continue to get new customers.
    - tomkarlo 16y ago
      That hasn't always held true for some of the major iPhone apps, at least - when there's a major version release, they sometimes require a new purchase. Also, iPhone and Android apps have the potential for ongoing in-app purchases by users. So you buy the GPS app once for a very low price (or free) but you have to keep buying the data updates if you're using it. Or new levels for Angry Birds.
billybob 16y ago
If the software is free, b) doesn't really apply. But I agree that a major version number should mean something - see http://semver.org/ http://semver.org/ Why not do fast development cycles that result in point releases? That, combined with background updates like Chrome does, would be great.

by Padraig 16y ago

Silhouette 16y ago

I don't mind faster releases if they're doing things we traditionally associated with minor version numbers, such as performance improvements or slightly UI tweaks. I really hope they don't change any rendering components at the same pace, though. I already have to strike any contractual obligation to test/support Chrome in commercial web development projects, because it's a moving target and Google do release breaking changes. If Mozilla browsers go the same way, then I really will start coding for the nice, stable, standards-friendly world of IE -- and that's never a statement I thought I would write on a serious forum with a straight face!

bzbarsky 16y ago
The plan is most certainly to make Gecko updates on a 3-month cycle. That means new features, bugfixes, etc.
nitrogen 16y ago
Can you give some examples of HTML/CSS-compliant layouts or layout features that were broken by changes in Chrome or Firefox?
- Silhouette 16y ago
  Please see my other post: http://news.ycombinator.com/item?id=2189846 http://news.ycombinator.com/item?id=2189846
- alanh 16y ago
  H.264 is scheduled to be broken in Chrome in exactly 6 weeks (given Chrome 9 came out this week)
- thristian 16y ago
  Recently I worked on a website with a lot of forms, and decided to use HTML5 form validation to make my life easier, with a JS fallback for older browsers. It turns out that Webkit added support for HTML5 form validation, then found a problem, so they switched off the implementation without switching off the exposed API. So every JS fallback that tests for the presence of the HTML5 methods on form elements will assume that HTML5 form validation is implemented, and leave the validation up to the browser... which doesn't actually do it at all. That means server-side validation, which of course one needs to do anyway. But it's not to hard to imagine somebody making a site during the brief window when Chrome supported HTML5 form validation, and then discovering their site broken in Chrome a few months later.
  - ahrjay 16y ago
    They didn't "switch it off" they merely turned off form submission blocking when the form was invalid. It's back on in chrome now because they have the error notification bubble. The constraint validition API, the error pseudo-classes and the extra attributes all work in Safari.
    - thristian 16y ago
      If the answer to "are the contents of this form valid" is always "yes", I don't really care how much of the validation API the browser supports; it's effectively going to waste. I'm glad to hear it's turned back on; I hope the form-validation interface is as sleek and professional-looking as the one in Firefox 4.

tomkarlo 16y ago

Arguably, the concept that ties major releases with major purchases is old and broken. It discourages companies from making major updates to software between such releases, as it will actually make it harder for them to make new revenue off the next major release. So you get point releases that are mostly minor bug fixes, and then a huge release every year or two that the maker hopes will squeeze you into opening your wallet, even if you're mostly happy with the last release. Web apps are clearly going to break this version treadmill. Even if you're downloading a package to the desktop, modeling software more as a service - you pay for the right to use software for a period including all updates, rather than for a perpetual license that in reality will expire and need to be re-purchased as soon as the next major version hits. Pay as you go is better for both users and developers. It means you can charge less up front, spend less on marketing (since the cost of trialing the software drops) and focus on delivering the _best_ experience to all your users rather than denying some features to existing customers in order to create a future revenue event.

Padraig 16y ago
Sounds great but I am never going to pay a subscription for my IDE, or my FTP program or my Twitter client. Relationships require trust and effort from both parties and it's simply not a perfect model for every piece of software. I don't want a relationship with a company. For most apps I want to buy and own a thing as it is now. This "old and broken" model persists because it's something that customers get instantly and can commit to knowing in advance what their full investment will be.
- skybrian 16y ago
  With Android apps (and iPhone I presume), it seems that you pay once and automatically get any available updates. I'd guess that would work reasonably well for small utilities, so long as they continue to get new customers.
  - tomkarlo 16y ago
    That hasn't always held true for some of the major iPhone apps, at least - when there's a major version release, they sometimes require a new purchase. Also, iPhone and Android apps have the potential for ongoing in-app purchases by users. So you buy the GPS app once for a very low price (or free) but you have to keep buying the data updates if you're using it. Or new levels for Angry Birds.

billybob 16y ago

If the software is free, b) doesn't really apply. But I agree that a major version number should mean something - see http://semver.org/ http://semver.org/ Why not do fast development cycles that result in point releases? That, combined with background updates like Chrome does, would be great.