Page 1 of 1
Triggering Spartacus repackaging
Posted: Sun Jan 29, 2012 4:26 pm
by 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
Re: Triggering Spartacus repackaging
Posted: Sun Jan 29, 2012 5:09 pm
by Timbalu
Yes.
Good question!
Re: Triggering Spartacus repackaging
Posted: Sun Jan 29, 2012 8:47 pm
by 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
Re: Triggering Spartacus repackaging
Posted: Sun Jan 29, 2012 10:26 pm
by yellowled
garvinhicking wrote: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.
garvinhicking wrote: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
Re: Triggering Spartacus repackaging
Posted: Mon Jan 30, 2012 8:26 am
by 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
Re: Triggering Spartacus repackaging
Posted: Mon Jan 30, 2012 8:46 am
by yellowled
garvinhicking wrote: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
Re: Triggering Spartacus repackaging
Posted: Wed Feb 01, 2012 11:02 pm
by 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.
Re: Triggering Spartacus repackaging
Posted: Thu Feb 02, 2012 7:31 pm
by 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
Re: Triggering Spartacus repackaging
Posted: Thu Feb 02, 2012 8:21 pm
by yellowled
garvinhicking wrote: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