silverstripe / silverstripe-framework

Silverstripe Framework, the MVC framework that powers Silverstripe CMS
https://www.silverstripe.org
BSD 3-Clause "New" or "Revised" License
722 stars 822 forks source link

[2010-01-16] Add a way to check current Sapphire/CMS/etc code version #1911

Closed silverstripe-issues closed 8 years ago

silverstripe-issues commented 11 years ago

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).

silverstripe-issues commented 11 years ago

comment by: @sminnee (sminnee) created at: 2012-04-18


Agreed, it would be handy. Probably best done as part of AJShort's module management work.

silverstripe-issues commented 11 years ago

comment by: @wilr (wrossiter) created at: 2013-03-26


Some work been done in this area, see LeftAndMain::CMSVersion(), API could still be extracted.

phptek commented 11 years ago

As at Sept 2013 the following are "implemented":

echo singleton('LeftAndMain')->CMSVersion();
// string 'Framework: 3.1.x-dev, CMS: 3.1.x-dev'
// Used in the CMS when hovering over the top-left logo

echo singleton('SapphireInfo')->Version();
// string 'Unknown'

Given that we've as good as retired the Sapphire brand, perhaps something more consistent, based on SilverStripe#Version() (where a "SilverStripe" class, replaces `'SapphireInfo')

Thoughts??

chillu commented 11 years ago

Yeah, in terms of dependency checks on modules, composer is the way to go. For most other things, I'd prefer feature detection (method_exists() etc). LeftAndMain is not really a good API for that. silverstripe_version is too specific to core as well, requires build tasks, only works on ZIP archives, so a dead end IMHO.

@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. Maybe the composer.lock logic can move from LeftAndMain to the new Module API? The composer/composer package will probably give us similar funcitonality, but it seems a bit extreme to include this in our default installation just to get version numbers.

wilr commented 11 years ago

@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?

chillu commented 11 years ago

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: https://github.com/silverstripe/silverstripe-buildtools/issues/3 @sminnee @hafriedlander Do you agree?

kinglozzer commented 8 years ago

Can this be closed? @tractorcow does cow handle @chillu’s above suggestion?

dhensby commented 8 years ago

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?

tractorcow commented 8 years ago

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!

chillu commented 8 years ago

Pointer to the composer.lock logic commit: https://github.com/silverstripe/silverstripe-framework/commit/2b6d735182c323e5943365cea70eba61753c7492

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 LeftAndMain, anybody's welcome to improve that :) @wilr's update reminder is a great idea, and implementing that could be the trigger to move the logic.

As far as this ticket goes, I would recommend using LeftAndMain->CMSVersion(). It's a public API, so functionality can rely on it, and we'll deprecate it if moving it around. Since there's not been any traction on this ticket for three years, and a solution (sort of) exists, I'm going to close it.