Triggering Spartacus repackaging

[yellowled]

Something I never really thought about: Correct me if I'm wrong, but in order to "trigger" a "repackacking" of a plugin on Spartacus (i.e. delivering a new version of a plugin to Spartacus), one has to increment the version number, right? Is it still that way with the new GitHub/SF mechanism?

Templates, on the other hand, usually don't have a version number. How do I trigger those?

YL

[Timbalu]

Yes.
Good question!

[garvinhicking]

Hi!

Yes, version triggering is still required for spartacus to indicate this.

Templates do not have a proper "version" key and increment, so there really is no "updating" for templates. For that you currently have to uninstall the template (delete the directory) and re-download it via spartacus. Adding a real version indicator to all plugins is some major cleanup, and in the past 6 years really important template updates were never required, so I wasn't really up for digging into this...

Regards,
Garvin

[yellowled]

For that you currently have to uninstall the template (delete the directory) and re-download it via spartacus.

Oh. I wasn't really aware of that. Guess it was good idea to always post "If you want the changes now, do …" hints here.

Adding a real version indicator to all plugins is some major cleanup, and in the past 6 years really important template updates were never required, so I wasn't really up for digging into this...

We should have that. Couldn't we just parse the info.txt for a change date?

YL

[garvinhicking]

Hi!

We should have that. Couldn't we just parse the info.txt for a change date?

The problem is that the "version" of templates was never really enforced. Current templates have all wild sorts of versions like "garvin1" or "2011-01-01" or "01.01.2011" or "1.0". This can't really be compared to deduce if a version is newer.

Maybe what can be done is without a version check simply see if the online version is "different", and we would mean that "different" is always "newer"...

Regards,
Garvin

[yellowled]

Maybe what can be done is without a version check simply see if the online version is "different", and we would mean that "different" is always "newer"...

Is that reliable enough? Not sure if this could be compromised by some timestamp being set the wrong way …

YL

[blog.brockha.us]

Why not use the version control for that?

Init a structure (xml files like we have in additional_plugins) with the current commit ids of the templates info.txt. If this commit id changes signal an update.

So it is irrelevant what kind of version the template owner uses, as long as (s)he updates info.txt it's a new version.

[garvinhicking]

Hi!

I think that's too hard. I think using the "version:" inside the text file is more reasonable to parse and fetch, since that is already evaluated.

Getting commit ids of a file would mean multiple CVS or git lookups, and maybe create sync trouble or lock the script to either CVS or git usage. I don't really like that, and would rather like to keep it simple for people to use the version string of a file...

Regards,
Garvin

[yellowled]

I think using the "version:" inside the text file is more reasonable to parse and fetch, since that is already evaluated.

Well, I guess it's safe to assume that most templates have never been updated anyway.

I still think versioning for template would be a good thing, but it's most likely not a pressing matter. If it's doable in a reasonable matter and someone finds the time to implement it, great. If not, so be it.

YL