Community
Participate
Working Groups
Build ID: Valgrind 0.7.0.201106060936 (==Indigo ==Linuxtools 0.8.0) As per the Linuxtools 0.8.0 release (Indigo), the Valgrind feature version is still at 0.7.0.201106060936. This is confusing for end users installing from the update site. I'd expect a 0.8.0 version not only because Linuxtools as a package is at 0.8.0, but also because Helgrind has been added which is a user-visible addition that does warrant a version update.
Feature versions are so much fun, aren't they? :) Let's make it 0.8.0 in Indigo SR1, Elliott.
What about 0.8.1 for Indigo SR1 ?
Sure, that's fine with me. It's becoming confusing enough for committers and consumers that we should probably just align everything to 0.8.1 for SR1, 0.8.2 for SR2, and then make them all 1.0.0 when we graduate for Juno.
Yeah... at least for the features. Plugin versions should continue to evolve by API evolution or remain unchanged if nothing changed.
While I fully support this alignment this is not a bugfix and bumping from 0.4.3 to 0.8.1 for specfile editor makes it look like a big change and this might be a problem for integrators that depend on feature versions. E.g you can't represent 0.4.3 to 0.8.1 as a bugfix release because it looks more like new version and according to Fedora guidelines newversion and bugfix updates are marked in different way and supposed to be given different testing. I know this is not blocking us but this can serve as a good example of what kind of issues this might cause to integrators. That's why I would prefer this to happen for 0.9.0.
Maybe we could do this just for Valgrind, arguing that it should have happened for Indigo (0.8.0) anyway?
(In reply to comment #5) > While I fully support this alignment this is not a bugfix and bumping from > 0.4.3 to 0.8.1 for specfile editor makes it look like a big change and this > might be a problem for integrators that depend on feature versions. E.g you > can't represent 0.4.3 to 0.8.1 as a bugfix release because it looks more like > new version and according to Fedora guidelines newversion and bugfix updates > are marked in different way and supposed to be given different testing. I know > this is not blocking us but this can serve as a good example of what kind of > issues this might cause to integrators. Yes, there are certainly potential problems with synchronizing the versions of unrelated packages. Perhaps a year or two from now, some of those features are not under significant development and just doing bug fixes. If they continue to appear as major new versions because of unrelated things happening in other Linux Tools components, it could also be confusing for downstream integrators who only are only consuming the stable features.
How about we just correct the Valgrind integration feature version to be 0.8.1 for Indigo SR1 (it should have been 0.8.0 in Indigo)?
Valgrind features and plugins now have version 0.8.1 in stable-0.8.