Do you want to go with the -dev prefix here?

I'd like to hold off on that until after our first release. The post-release tool can add that automatically.

Could you add a readme or some other file that will stick around in each of these directories to explain how they are supposed to work?

Or we at least need to have a good explanation somewhere that is easy to find.

No version here? I guess we don't need it since it won't be published.

If we never run pack create on it, we really don't need a version at all.

Maybe we should make sure it is an error to run pack create on a pack that doesn't have a version. Not sure what the behaviour is now.

So, the move from an explicit version to a * is ok because we are OK with users who try to compile codeql/java-all outside of this workspace getting an error?

Wait, let me think about this. For library packs this probably isn't right, because we want a real version dependency in the published library pack.

Ah...yes. I think we need a hard version.

This complicates the upgrade process since we will need to bump the upgrades dependency as well.

For this release cycle, let's bump the upgrades references manually, but this should be very high on our list for automation since it is easy to screw up or forget a pack.

How easy would it be to merge upgrade packs into the codeql/*-all packs?

Do we want to bump all of our libraries to 0.0.4 so we can at least start with consistency?

I thought about that, but all our version numbers will diverge soon enough anyway, so I figured I'd leave the inconsistency in there so people get used to it:)

Why are change notes and the codeql-pack.release.yml file stored in an arbitrary sub folder (codeql) containing also QL code instead of the pack root folder? In contrast to other languages that use semmle.code, Ruby uses codeql as top-level package name. It feels wrong to "pollute" the QL package folders with qlpack metadata.

Oh, thanks for pointing that out! We'll either change the name of the directory where the extra pack metadata is collected, or just store it in the root (which would mean that there would be a top-level change-notes directory in your pack, but that actually seems more discoverable than codeql/change-notes).

Fixed.

@dbartol I'm fine with this change, but I was wondering what prompted you to make it? It is to make things more consistent, or did you need to change this to workaround some technical limitation/complication?

Personally, I'd rather see language specific stuff in per-language manifest files and keep the top-level manifest clean. Of course doing things inconsistently like we had before is worse, so we should either move:

        "cpp/ql/test/query-tests/Security/CWE/CWE-190/semmle/tainted/qlpack.yml",
        "javascript/ql/experimental/adaptivethreatmodeling/lib/qlpack.yml",
        "javascript/ql/experimental/adaptivethreatmodeling/src/qlpack.yml",
        "ruby/extractor-pack/codeql-extractor.yml",
        "ruby/extractor-pack/codeql-extractor.yml",

out of this file, or keep them all in the top-level file like you did. I have a slight preference for moving things out, but I leave it up to you to decide (or flip a coin ;-) )

The .codeqlmanifest.json (or its modern equivalent, codeql-workspace.yml) file defines a "CodeQL Workspace", which includes settings that apply to all packs directly contained in that workspace. That's where the set of available change note categories are defined, the versioning policies, and so forth. If we leave Ruby in its own, it would need its own copies of these policies.

Also, pack dependencies are automatically resolved when the target pack is in the same workspace, so with a separate .codeqlmanifest.json for Ruby, the codeql/suite-helpers pack can't be resolved by default unless you run codeql pack install to download a published version, or add a --additional-packs path to the command line.

I'm not sure I completely follow what you say. The .codeqlmanifest.json file existed before the concept of "CodeQL Workspace" was invented, right? I suspect the semantics of .codeqlmanifest.json has been retro-fitted (and changed) to match the idea of a "CodeQL Workspace".

Isn't the problem here is that you don't seem to allow "nested" workspaces? A bit like maven's idea of a "parent" pom file? No need to implement nested workspaces, the simple solution of having only one large workspace is fine with me. I'm just trying to understand things.

I prefer to think of it as ".codeqlmanifest.json has evolved and expanded to become a 'workspace'". Originally, .codeqlmanifest.json was used to allow you to add a single directory to your search path, but have the search look in many different paths under that directory. That aspect of it still applies. However, we now automatically resolve references between packs within the same workspace. Without Ruby being in the same workspace as the suite-helpers pack, you'd need to specify a search path. Before workspaces, you would have always needed a search path.

We currently support nested workspace in a somewhat limited sense: A pack in a parent workspace that references a pack in a nested workspace will automatically find the pack in that nested workspace. However, a pack in a nested workspace will not find packs in the parent workspace, nor in sibling workspaces. An early implementation of workspaces actually had this feature, but it was removed during review because we didn't actually have a real-world use case for it at the time. I'm open to adding that feature back, but I'm not sure I'd do it just to make one of our own workspaces only slightly cleaner.

Thanks for the explanation!

@dbartol What is the purpose of this file? To me it feels strange to keep this data in the source tree. It's yet another file that will cause conflicts on merge back. It looks like the same value is stored in each of the qlpack files.

This stores the version number of the most recently released version of the pack. That will not necessarily be the version that is committed to the qlpack in main after the release. The codeql pack post-release command (see github/semmle-code#40925) can update the committed version number to have a prerelease suffix so that builds of a package from main are not confused with official releases. We already do something similar for the CLI version itself.

Because these files are only updated by the codeql pack release command, the only way to have a merge conflict is if a later release was merged back to main before a previous release was merged back. This could theoretically happen with a servicing release (say, we released version 2.0.0 of a package, but then discovered a serious issue in 1.5.4 and released a 1.5.5 that fixed to for customers who weren't yet ready to update to 2.0.0). However, this should be rare enough that manually resolving the conflict in favor of main won't be a big deal when it does happen.