Posted by stevector on September 7, 2011 at 11:21pm
| Project: | Features |
| Version: | 7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | reviewed & tested by the community |
Issue Summary
It looks like drush could support using a flag of --version-number or --increment-version when running drush features-update. Would such a patch get accepted? Any trouble spots to watch out for?
Comments
#1
I think --version-number would be the way to go. If you want to look at implementing a patch I'll review it.
#2
This would be great,
I'm not using "drush features-update" at the moment only because it can't set a version
#3
@ahwebd You realize version number is trivial to set in the .info file?
I agree, --version-number seems good. But really, where does it stop? Maybe there should be a master flag to just set things into the .info file. That way drush fu could set the package, or kit compliance, random additional dependencies, etc.
--info-version=6.x-2.3 --info-dependency=spaces --info-dependency=admin#4
drush features-add feature_module dependencies:spacescan be used to add dependencies in the -dev version, a separate switch isn't needed.#5
Of course any version number handling in features-update should also be applied when using features-add :)
#6
Marked #1406166: Allow Drush to update features' version as duplicate
#7
I'm very interested in this issue as I hate manually updating my info files every time :)
Seems simple enough, I'll try to work on a patch later on today.
#8
Since drush_features_update() calls _drush_features_export(), which is also called by other functions, this functionality would end up being semi-global and the --version option would be available to:
More on this soon! :)
#9
Ok, this was actually easier than it looked! :)
Attached is a patch that implements this. The option is --version. (--version-number is kinda longwinded to type)
Caveat: there is no validation in place for the version number (yet).
#10
Ok, this patch now uses the same validation regex as features.admin.inc and prints a notice and dies on invalid version numbers.
Afaik its good to go, can anyone else test this please? (patch against -dev release)
Thanks! :)
#11
Attached is an alternative patch that extends the functionality of the previous patch to allow automatically incrementing a feature's version number.
Setting a feature number manually:
drush fu featurename --version=7.x-1.0Setting a feature number automatically:
drush fu featurename --version=incrementFeedback anyone?
#12
oops :)
#13
Yes, please. :)
I'm not really using drush to manage feature updates until this functionality is in. The version numbers is important to me and my development process
#14
I realize the feature devs are probably really busy but it'd be great to have someone review and hopefully commit this patch. I've tested it a lot and it's pretty solid IMO. :)
Thanks!
#15
I sort of agree with #3. There are a whole host of things that can be specified in the .info file. Description, package, kit/debut specs, etc. Adding options to drush fu doesn't seem like the most sustainable solution.
What about a drush command to open the .info file for the feature in a text editor?
drush features-edit featurename?
#16
I'd say what's really needed is to take the work going on in issues like #1331278: Drush features-add and features-export are confusingly similar, and overly verbose a step further, and allow arbitrary component additions via command-line parameter. Afterall, adding a component to a feature for export is really just a modification to the $info array constructed or loaded into memory before it's processed by the export routines. That info array is then written out to the .info file.
#17
febrraro said "I think --version-number would be the way to go. If you want to look at implementing a patch I'll review it.".
It's implemented in #10.
Grayside I agree that there's a million different and potentially better ways about going with any implementation but this is a much needed and simple feature. I dont't understand why we can't just accept this solution for now and move on to greater things in the long run?
Anyone who works with features knows what a pain it is to have to manually increment version numbers after updating with drush fu.
My 2 cents.
#18
This does seem to be a useful patch, thanks alex for your work. I realize the below is mostly bikeshedding...
1) The --version option does not seem to conflict with the global drush --version option, but it seems like a best practice would be to not choose options that match global drush options.
2) When you choose --increment, if your existing version is something like 7.x-1.0-dev, it becomes 7.x-1.0-dew. I realize this is a corner case. It works if your version is something like 7.x-1.0-beta1 (becomes beta2). Not sure if you intended this though.
#19
Hi Joel, good call, I should have checked for is_numeric() before incrementing.
Any suggestions on what the option name should be?
#20
Attached is a patch that fixes the minor issue spotted by joelcollinsdc in #18
I'd be happy to refactor the option name if a better suggestion exists, I can't think of anything at the moment that would be different than "--version" without being confusing. Perhaps using "--increment", but this would break the request that febbraro made, of allowing the version to be manually set.