Can a crate use an older version of itself as a dependency?

If I have a crate foo version 1.0.0 and I decide to start work on e.g. 1.1.0, can foo 1.1.0 use foo 1.0.0 as a dependency?

I'd test it out myself but it seems better to ask the question than to pollute the crate namespace for the sake of what should be a simple yes-or-no answer.

2.x can use 1.x of itself, but you can't have two different semver-compatible versions of a library in the dependency tree.

I see.
So just to clarify, the dependency tree is rooted in (and thus contains) the crate doing the importing?

It doesn't matter where it's rooted. You just can't have 1.0 and 1.1 of the same crate anywhere in a single project.

1 Like

Okay. All that really means is that my usage of semver will shift to always updating the major version (and not bothering with minor/patch versions) in order to use the previous version of the crate.

Why do you want to do this?

I'm experimenting with combining a PEG-style parser with compiling the rules for a grammar right in, i.e. once compiled there's just a parser, no need for locating parse tables first.
This means that at compile time, the parser crate needs to be able to parse the grammar, which I want to write in an EBNF-style language.

At this point it starts looking like a bootstrap problem, one solution for which is to use previous version of the project in question. Of course that doesn't help me with the initial version, but that can be relatively quick-and-dirty as long as it gets the job done.
Ultimately I want this to be maintainable too, especially if the experiment pans out.

1 Like