Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to master sorcery by Ismael Luceno (ec486fc52b559dfb41e94437fb5fb8d2389d2382)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: Ismael Luceno <ismael.luceno AT gmail.com>
  • To: Remko van der Vossen <wich AT yuugen.jp>
  • Cc: sm-commit AT lists.ibiblio.org, Ismael Luceno <ismael AT sourcemage.org>
  • Subject: Re: [SM-Commit] GIT changes to master sorcery by Ismael Luceno (ec486fc52b559dfb41e94437fb5fb8d2389d2382)
  • Date: Mon, 12 Jan 2015 10:55:28 -0300

On Mon, 12 Jan 2015 12:58:19 +0100
Remko van der Vossen <wich AT yuugen.jp> wrote:
> On Sun, Jan 04, 2015 at 01:16:35AM -0600, Ismael Luceno wrote:
> > libqueue: Implement proper version comparison
>
> I don't think I like this. version comparison is an incredibly fickle
> thing. Furthermore, I don't think it has any place in queueing.

Why not?

> Version comparison is very much something that I would like to see
> supported in sorcery. The reason however is not queueing, but proper
> dependencies. Many times particular versions of spells need particular
> versions of other spells, it would be very worthwhile if we could
> express this properly in the dependencies.

I have plans for that!

> Proper version comparison is however extremely difficult to do right,
> version naming conventions vary enourmously among spells. A simple
> lexographical ordering is never going to work. There will always be
> examples where this will fail. Therefore we can only implement a
> default in sorcery itself, but will need customizaibility within the
> spells themselves with e.g. some optional version comparison function
> in the spell.

Agreed, it's a tough topic to deal with.

But we can mitigate the cases where it doesn't work with:
A) Improving the function :P (I'm still working on it).
B) Custom version prefixes (e.g. when the version scheme changes).
C) Allow to specify a sed transformation on the version (probably
not necessary, but we can leave room for it).
D) A mechanism to force it to do just plain string equality comparison.


> Besides that, who says that a downgrade is not a reasonable thing to
> do? If I was running on stable, switched to master, but then decided
> that the system is not workable for me and wanted to switch back. That
> situation would be unworkable with the updated version.

IMHO, it's not reasonable _default_ behavior. Grimoire-wide downgrading
should be implemented in some other way, something explicit.

> Similarly, there could be a new version of a spell in the grimoire
> which breaks some things for me, so I make a local spell using an
> older version. The cast however doesn't work so I need to force it
> for no good reason.

Why not? or you mean the queuing?

> Finally there may be very good reasons for
> downgrading a spell in the grimoire itself; there may be security
> issues with a new version, crashing issues, whatever. If we revert an
> update it is for good reason and the systems tracking the grimoire
> should follow suit.

If that's the case, SECURITY_PATCH would have been incremented...

Attachment: pgpFSotTsz_iE.pgp
Description: OpenPGP digital signature




Archive powered by MHonArc 2.6.24.

Top of Page