Posted by dww on November 27, 2007 at 11:52pm
Yes: include the exact version of core in the version string (5.3-1.0)
44% (18 votes)
No: maintain the status quo (5.x-1.0)
56% (23 votes)
Total votes: 41
Should the version strings for installation profiles include the exact version of core they contain?
Comments
Explanation and analysis
This poll is part of the upcoming effort to package installation profiles with all of core and whatever contributed projects they depend on.
Because of core maintenance releases (bug fixes and security updates), it will be important to know (and update) the version of core packaged with each install profile. This has potential implications for the version strings (and therefore CVS tags) that are associated with installation profiles. There are two primary options:
Both approaches have pros and cons, so read on...
#1: Include the exact version of core in the version string
The version strings for install profiles would look something like this:
5.3-1.0The
5.3is obviously the specific version of core for that release of the profile, and the1.0part gives profile maintainers the existing flexibility for multiple versions of their profile that work with the same version of core.The CVS tag for this release would be:
DRUPAL-5-3--1-0Allowed CVS branches for install profiles would be just like now:
DRUPAL-5(Evil special case from before, now gone in D6)DRUPAL-5--2DRUPAL-6--1DRUPAL-6--2...
You don't need a whole new branch for each specific release of core, so we won't include that in the branches. Instead, it'll work just like now: the first part of the branch says the core series the profile is for, and the second part (e.g. the
--2) says which branch of the profile you're dealing with. I don't imagine most install profiles will have multiple branches of development in the same way that modules do, but it seems like we might as well keep the flexibility (since we're already used to it), just in case.Pros
Cons
#2: The status quo
Install profiles are numbered and tagged exactly as they are now -- just like the rest of contrib.
Pros
Cons
Conclusion
Given the large potential for confusion with the new approach, I'm leaning towards keeping things the way they are. The nightmare of subjecting the Drupal community to yet another change in version numbers is rather scary. On the other hand, the existing convention just doesn't make much sense for install profiles, since you really want to know the version of core as a key element of the version string. It doesn't make sense for core translations, either, for much the same reason. See http://drupal.org/node/89969 for background on that.
finding problems in code
I'm thinking more and more that we need some automated script2issuequeue module that will find errors like this one, or like not using db_query etc. and then create an issue in the queue. I know this isn't the place for adding more features, but the possibility of doing that is part of why I'm voting for option #2 - it mitigates what I see as the biggest problem with that proposal :)
--
Knaddisons Denver Life | mmm Chipotle Log | The Big Spanish Tour
knaddison blog | Morris Animal Foundation
Unclear
In #2, what version of core would be in the tarball? Always the latest release? Thats what I would prefer, so we don't distribute insecure drupals.
Core version would always be explicit in the profile...
Sorry if this wasn't clear -- I wrote much of this text on a plane ride home. ;)
I don't think it's possible to always automatically include the latest stable release. That'd mean the install profile tarballs would change code without a new version number. This violates a fundamental principle of the release system: everything with the same name must always be exactly the same code. Yes, as much as it sucks in some ways, I think that for every core point release, the install profile maintainers should have to update their profiles and create new releases, pointing to the new version of core. The alternative is a dangerous regression to the dark ages before the release system, where you were never really sure what code you had based on the version string you were looking at. :(
Plus, it's possible a core point release might break something about the install profile (or the modules it depends on), and even though the 5.x-1.0 release from yesterday worked fine, now that it includes 5.4 core and doesn't actually work anymore. And, we're right back to "what day did you download the profile?" hell.
So, if we go with #2, and use "5.x-1.0" as the version string for installation profiles, they'd still have a specific version of core inside them (e.g. 5.3), you just wouldn't know what it is based on the version string. You'd have to either a) find it in the release notes or b) download the thing and look for yourself (as I explained in the original analysis comment). But, once if/when a 5.4 core release is out, there'd have to be a 5.x-1.1 release of that install profile which included the 5.4 core release.
Status quo sounds easier to
Status quo sounds easier to deal with - asking developers to put "this profile uses Drupal 5.4" is less work than learning new CVS tags. It's quite possible to download old, insecure versions of modules from Drupal.org if you really want to, and the extra complexity wouldn't stop people from doing that.
Fair enough - warnings
You maker a compelling argument for consistent code for a given release. Lets take that as a given.
But we cannot have people easily downloading insecure versions of Drupal. I know thats possible today, but we hide those releases a bit. In the same way, we have to hide (or discourage) install profile releases that are packaged with a core that has known security bugs. One might even argue we should hide if the install profile comes with a known security buggy contrib module.
Perhaps the cleanest solution is for a warning abel to show as needed on the download page which says something like "This installation profile is bundled with the following known insecure components: Drupal 5.2, Chatroom 1.3".
Agreed -- hence the core version directly in the string...
Right. I want to make it easy for everyone involved to know exactly what version of core is included in a given installation profile. That's what made me want to put this information as a first-class element in the version string. Then, it's trivial to do fancy warnings, hiding, whatever. Otherwise, we have to parse and store this information somewhere else (a new DB table seems wrong, but if it's not the version string, it doesn't belong in the {project_release_nodes} table, either). This is definitely a case where d.o-specific functionality runs up against the project* codebase. It clearly needs more thought. In fact, there's no good way to put the exact core version directly in the version string given the current project_release code. :( So, either way we're going to have to change something under the covers to make this work better, the question is what and where.
Anyway, yes, the security implications are exactly what prompted this question in the first place. This is the #1 pro I listed above with changing the version strings. But, it's true that only changing the version strings wouldn't solve the problem, we need even more functionality to make this really slick. Seems like I might need to increase my estimate for how many hours/days it's going to take for me to implement all of this... ;)
I don't think we should tie a
I don't think we should tie a profile release to a specific core version.
Let's assume a profile is tagged and a corresponding release node created.
I think the profile author should be able to specify minimum versions (the desired version) for each module (and core) in the profile. Maybe this is subject to some validation at create time, or packaging time to insure that the minimum versions are not behind any security releases.
If there is a security release for core or a module, we should automatically build a new tarball with a version suffix - e.g. indicating it's a patched version of the original profile.