-
Notifications
You must be signed in to change notification settings - Fork 821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[2010-01-16] Add a way to check current Sapphire/CMS/etc code version #1911
Comments
comment by: @sminnee (sminnee) Agreed, it would be handy. Probably best done as part of AJShort's module management work. |
comment by: @wilr (wrossiter) Some work been done in this area, see LeftAndMain::CMSVersion(), API could still be extracted. |
As at Sept 2013 the following are "implemented":
Given that we've as good as retired the Sapphire brand, perhaps something more consistent, based on Thoughts?? |
Yeah, in terms of dependency checks on modules, composer is the way to go. For most other things, I'd prefer feature detection ( @ajshort doesn't seem to have a notion of version getters implemented in his GSOC work, see https://github.com/ajshort/sapphire/blob/composer/src/SilverStripe/Framework/Core/Module.php. |
@chillu, I ran into this the other day as well. It would be useful to have an API for checking the version in order to provide end user feedback about new security releases (like wordpress, drupal) I think running unprotected builds is going to rear it's head sometime and the best way is user centric (developers won't remember all their apps), other systems notify via the backend. You wouldn't be able to update through the backend but at least it'll prompt the user. Can we use something like a post commit hook to append some sort of meta data with the current version information therefore agnostic between composer and static downloads? |
You mean writing the SHA of the latest commit to a file in the repo? That'll either add an additional commit for each commit we make, or it adds weird changes to the diff which will confuse the hell out of devs ;) My vote goes to committing silverstripe_version on each tag, and setting it to the branch name as a one-off activity each time we create a branch. That's only a feasible solution for core (and its build process), but frankly I don't see any easy way for module authors to do this. Created an issue here: silverstripe-archive/silverstripe-buildtools#3 @sminnee @hafriedlander Do you agree? |
Can this be closed? @tractorcow does |
It's be good to do that as part of the tag, I guess. But couldn't we now use composer to find this out? |
It's done on the archive, but NOT on the tag, currently. https://github.com/silverstripe/cow/blob/master/src/Steps/Release/BuildArchive.php#L191 I prefer the suggestion of moving the composer.lock logic out of LeftAndMain and into another core class. Adding more "meta" commits to each tag makes release more complicated, and introduces the risk of development branches having incorrect versions included. Don't hard code what you can infer! |
Pointer to the composer.lock logic commit: 2b6d735 I agree with @tractorcow in that we should try to infer this information rather than clutter the commit stream on each tag. In which case, the functionality is already in place. Yes, there's probably a more generic place for it than As far as this ticket goes, I would recommend using |
created by: dalesaurus
created at: 2010-01-16
original ticket: http://open.silverstripe.org/ticket/4924
Perhaps I've missed it but I see no way to figure out what version of SS (cms, sapphire) you are running. I see this is done in LeftAndMain.php and the SapphireInfo.php controllers via some file_exists and regexes, which are not ideal to duplicate.
It would be helpful for modules to be able to check what the current version is. In my case it would be knowing where to locate the Third Party directory to include stuff per 2.3 vs 2.4.
I would suggest either defining some global constants like so:
define(SS_CORE_VERSION,'2.4.0');
define(SS_CORE_MAJOR,'2');
define(SS_CORE_MINOR,'4');
define(SS_CORE_REVISION,'0');
Or put the code from SapphireInfo->Version into a static function somewhere handy, like Requirements to be used to check requirements in addition to setting them.
Again I apologize if this exists, but it is pretty common among other frameworks I've used. Of course this could open a larger discussions as the modules would need a systematic way to report their versions as well as check versions of other modules they rely on (like cms).
The text was updated successfully, but these errors were encountered: