Version numbering for projects with multiple targets

Help & Support
1

Hi,
I’m working on a personal project which results in the writing of 3 applications, which share part of their source code.

In this project P, the structure of the files looks for example like this :
Application A : Source files app_a.cr, a1.cr, a2.cr, a3.cr, a4.cr, …
Application B: Source files app_b.cr, b1.cr, b2.cr, a1.cr, a3.cr, …
Application C : Source files app_c.cr, c1.cr, c2.cr, b1.cr, a4.cr, …

For the moment, I have organized the file tree in the following way:

project_p/
  src/
   app_a.cr
   app_b.cr
   app_c.cr
   app_a/
       a1.cr
       a2.cr
       a3.cr
       a4.cr
       ...
   app_b
       b1.cr
       b2.cr   
       ...
   app_c
       c1.cr
       c2.cr
       ...

and with the appropriate “require” in code and appropriate “targets” in the shard.yml file, everything is ok.

Except that I wonder about the question of how to manage the version numbering. Each of the 3 applications has logically its own numbering, but the shard.yml file can only contain one (the one of the project P, but not defined as not used!). I guess, however, that this can only become a problem if the project is published.

Nevertheless, I would be happy to know the most appropriate solution in this case. For example, would it be better to split the project into 3 subprojects, with symbolic links to the shared source files?

Or is there a better solution?

Thanks for your advice.

2

Probably yea, then just install/version them as you would any shard. You can use private shards, so they do not need to be public either.

See also: Multiple shards in a single git repo?

3

If the 3 apps are related and part of a big thing/package, you can consider the shards.yml version number being the version of the big thing/package, So for each app you could show both version numbers, the big thing/package version and the app version.

If there are 3 different not related things, better split in 3 repositories.

I wrote a macro 2 years ago that help you to keep in sync the version number in shards.yml with the VERSION constant people usually have in their programs:

4

There can only be one shard in a single git repository. Thus, if you want to distribute these applications as individual (sub-)projects with independent versioning, you have to put them in separate repositories.

Symbolic links for shared code can’t work if the applications are supposed to be installed via shards. You need to define all dependend code as dependencies. For example, besides the three application shards, you could have a fourth shard with shared code.

This obviously creates a lot of friction. Keeping dependencies in sync can become an effort.

Keeping all applications in a single repository creates less maintenance overhead. I’d recommend to keep it that way unless you really need them to be independent shards.

It obviously depends on your specific use case. But is it actually that much important to have separate version numbers for each application? If these applications belong together as parts of a project, what’s the reason to separate them? There should be no harm in using a collective version number. It just makes live much easier.

You could of course use different internal version numbers for each application, independent of the metaproject’s version as suggested by @hugopl. That should work, but I’d question if it’s worth it. Again, it’s more effort (although less than maintaining separate repos) and I don’t see an immediate benefit.

5

Thank you all for your suggestions.
After thinking about it, I agree with @straight-shoota and choose to make it simple: a unique version number for the 3 applications, with the use of @hugopl macro to facilitate the update in each application.