Avoiding SilverStripe Version "Unknown"

[James Cocker]

Is there anyway that silverstripe_version can contain a version number if a stable version is retrieved from github? Can one somehow be inserted when a stable version is created, and then removed with another commit?

I've started looking at using Composer to keep all my SilverStripe sites up-to-date, but I can see me losing track of all their versions if I'm unable to easily tell which version is installed while logged into the CMS.

If there is no way at all of getting the version number into silverstripe_version then do you have any recommendations for easily finding out the current version. I know I can check in composer.lock, but I'd prefer a more accessible way.

Thanks
James

[James Cocker]

Just seen a discussion about this between Simon and Sam in an IRC log from November: http://logs.simon.geek.nz/index.php?date=2012-11-01#14_59

They talk about making the create-release script commit the version number to silverstripe_version, and then have it perform another commit to update it to a dev of the next version.

Is this still something that's still on the cards? As it would really help when using composer.

[Ingo Schommer]

There's "composer show --installed". We can't use this in the CMS UI,

because a) we don't want a shell call from there and b) its not always available.

But: I'd like to have some kind of "phpinfo for SilverStripe", which shows

you all kinds of info about your environment: env vars, server versions,

operating system, webroot, temp paths, SilverStripe version, etc. 

This would greatly help with bug reports, but also with keeping

an overview of your own install base. Would that solve your problem?

We already have the base for this with the "developer toolbar" (http://sdevtb.blogspot.de/),

although it'd be great if the environment info could be used independently, so we can backport it to 2.4

without introducing a major new feature.

The build tools where we write the silverstripe_version on ZIP packages are all open source BTW:)

https://github.com/silverstripe/silverstripe-buildtools

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[James Cocker]

A phpinfo type screen for SilverStripe would be great! But building in a couple of commits to update silverstripe_version in the build scripts would still be really handy, and possibly still required in order to do a phpinfo thing.

I've taken a look at the build tools source, but wouldn't know where to start!

James 

[Sam Minnée]

I wonder if we can get the data out of composer.lock / composer.json, if they exist? Seems like a reasonable optional call to make in the code that currently reads silverstripe_version. It would need to be defensively written, so that the consequence of a Composer format change was merely that the version number does show, and not an error message. But that seems relatively safe.

[James Cocker]

Ok, I've had a bash at this: https://github.com/purplespider/silverstripe-cms/commit/10c6919cb7942cba8a22dc71b7e0a4d81f33ba93

I've tested it with the following scenarios, and it seems pretty robust:

• composer.lock doesn't exist
• composer.lock isn't valid JSON
• "packages" doesn't exist in composer.lock
• the cms/framework packages do not exist in composer.lock
• "version" doesn't exist for the package in composer.lock

It will just return "Unknown" as normal, if any of those are true.

Let me know if this looks ok, and I'll issue a pull request, wouldn't be surprised if something could be improved though!

James

Purple Spider Web Design

purplespider.com

[Ingo Schommer]

Hey James, thanks for looking into this!

Looks good in general, but I think we need to cache the value.

We don't want to parse a rather large JSON file every time the CMS is opened, right?

Either through SS_Cache directly, or through partial template caching, set to 24h+ expiry time?

[James Cocker]

Very true! We'd want the cache to expire when an update to Silverstripe is performed though. Otherwise it may cause confusion and make it look like it's still the old version that is running. Do caches automatically expire on an upgrade? Or shall this need to be manually developed? As I'd be unsure how to achieve that if the latter.

James

Purple Spider Web Design

purplespider.com

[Ingo Schommer]

You can force this by including the last modified date of the composer.lock file in the cache key.

[James Cocker]

Ok, I've never actually used SS_Cache or similar before, but this appears to be working well now: https://github.com/purplespider/silverstripe-cms/commit/c8b2ea5d45d170603726962c16b07609e8a94134

I'd again be interested to hear if it can be improved at all.

I see that the CMSVersion method also exists in LeftAndMain.php in framework, should I also replicate this feature there?

James

Purple Spider Web Design

purplespider.com

[James Cocker]

I've just realised I've done this on 3.0 as opposed to 3.1, is that the reason the pull request hasn't been accepted yet? https://github.com/silverstripe/silverstripe-cms/pull/289
Should I also do a pull request on 3.1? Sorry, I'm new to contributing!

James

James

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.

Visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.

Visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.

Visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.

Visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-dev+unsubscribe@googlegroups.com.
To post to this group, send email to silverstripe-dev@googlegroups.com.