I’m contemplating releasing a version of Vegetables with the parallel features removed. This will make it easier for codes that don’t use parallel features and possibly even use compilers that don’t even support them, to use vegetables without having to worry about it. Due to the version identifier constraints of fpm, it makes sense for them to be separate packages, the question then becomes how to name them.
If it’s possible , can we call parallel version of vegetables as broccoli. My idea is that broccoli contains a thick stem part, and as we go up it diversifies into small branch like structure, just like a tree. Branches represent that the code is parallel.
Thanks for the suggestions guys. I too was leaning towards “vegetables, parallel-vegetables”, and possibly naming “parallel-vegetables” something else, so those suggestions and the poll further push me in that direction. I’m leaning towards vegetables and garden, because a garden grows multiple vegetables. The suggestion to rename to “veggies” is tempting as well. I’m not quite sure if it’s worth the bit of loss in continuity, but I’m considering it.
Why isn’t it possible to solve this with branches and tags? vegetables = { git = "...", branch = "serial" } vegetables = { git = "...", tag = "v7.4.3-serial" } ← preferred way
Which “version identifier constraints” do you mean?
IMHO it’s confusing to have two names for one library (parallel-vegetables would be OK, though).
This is what I initially had intended to do, but fpm tells me this is not allowed:
version = "7.4.3-serial"
Versions are only allowed to contain numbers and periods. Common usage now will allow branches and tags to work for users, but when we get the point of just needing to specify name and version, that won’t work.
Optional features could be a solution, but I’m not quite clear exactly how that will work and how I would code to it. And since it’s not available, not usable in the short term. If/when that’s available I will give it a try.
That could be adopted for fpm, if we decided it was beneficial for us, but it does complicate version constraint solvers. I.e. is 1.0.1 before or after 1.0rc1? What about 1.1.0? If I specify I’d like a version > 1.0, does 1.0rc1 satisfy that? I’m of the opinion we probably want to have an automatic version constraint solver built into fpm, similar to what cargo does, but others may have a different opinion.
IMHO fpm should use Semantic Versioning for packages. In this case a ‘-’ separates the version core (1.2.3) and the dot-separated pre-release identifiers. But there is also a separator for the dot-separated build identifiers, which could be used for a parallel and a serial build: e.g. version = 7.4.3+serial.
Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows:
Identifiers consisting of only digits are compared numerically.
Identifiers with letters or hyphens are compared lexically in ASCII sort order.
Numeric identifiers always have lower precedence than non-numeric identifiers.
A larger set of pre-release fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal.
That means that version 1.2.3-parallel would be interpreted as a more recent pre-release version than 1.2.3-serial.
Managing a git repo with essentially two different codebases would also be a headache. Personally I would keep them in to separate repos. I don’t know the internals of vegetables, but maybe it’s also possible that the parallel version would depend on the serial version? In that case two repos would make even more sense.
I voted “other” and would like to second @alozada’s orchard for parallel version of vegetables with coarrays. My extra $0.02 on top of that would be to rename the serial version of vegetables into singular vegetable without the s.
So, vegetable and orchard.
: 
. So can we write something like this