5.7 release / 6.0 roadmap

[florentsfl]

Here is a thread so we can discuss about what we want for 6.0 and what we should show as "soon deprecated" in 5.7

5.7

• Add warning about cqfd run command arguments... that should go for deprecation
• Add CQFD_RUN_WITH_SUDO
• Add CQFD_DIR and CQFDRC_FILE, could be in 6.0 as the -d option is slightly modified to handle absolute path
• Fix/allow using without local dockerfile, that implies to split custom_img_name in two different options image=ubuntu:24.04 and tag=cqfd_%Un_%Po_%Pn_%Ph
• Simplify ini parsing once again (:crossed_fingers: it is the last change)
• Optionize --init and --release

6.0

• do not handle semicolon comments in .cqfdrc (breaking change)
• do not remove whitespaces around assignment in .cqfdrc (breaking change)
• remove entirely cqfd run in favor of cqfd exec and cqfd shell. And may be go for a sudoization (or shellization) defaulting cqfd to either cqfd exec (or cqfd shell) (big breaking change).
• maybe remove custom_img_name in favor of image and tag (breaking change)
• use BATS testing
• Either remove .cqfd/ directory and use Dockerfile in the work-tree (top directory) and add dockerfile=Dockerfile option so set the location of the Dockerfile to use. Rename .cqrdrc or support multiple cqfdrc file lookup Cqfdfile, cqfdfile, .cqfdrc or move the .cqfdrc to .cqfd/config

[florentsfl]

@gportay I can edit the primary post with your suggestions

[gportay]

5.7

• Add warning about cqfd run command arguments... that should go for deprecation
• Add CQFD_RUN_WITH_SUDO
• Add CQFD_DIR and CQFDRC_FILE, could be in 6.0 as the -d option is slightly modified to handle absolute path
• Fix/allow using without local dockerfile, that implies to split custom_img_name in two different options image=ubuntu:24.04 and tag=cqfd_%Un_%Po_%Pn_%Ph
• Simplify ini parsing once again (:crossed_fingers: it is the last change)
• Optionize --init and --release

6.0

• do not handle semicolon comments in .cqfdrc (breaking change)
• do not remove whitespaces around assignment in .cqfdrc (breaking change)
• remove entirely cqfd run in favor of cqfd exec and cqfd shell. And may be go for a sudoization (or shellization) defaulting cqfd to either cqfd exec (or cqfd shell) (big breaking change).
• maybe remove custom_img_name in favor of image and tag (breaking change)
• use BATS testing
• Either remove .cqfd/ directory and use Dockerfile in the work-tree (top directory) and add dockerfile=Dockerfile option so set the location of the Dockerfile to use. Rename .cqrdrc or support multiple cqfdrc file lookup Cqfdfile, cqfdfile, .cqfdrc or move the .cqfdrc to .cqfd/config

[gportay]

Of course the breaking change are subject to discussion.

cqfd [--release] [--init] [-C DIR] [-d DIR] [-f FILE] [-b FLAVOR] [-q] [--verbose] [-h|--help] [-v|--version] [-] [PROGRAM] [ARGUMENTS...]

This implies removing all the commands init, exec, flavors, run, release, shell and help.

[florentsfl]

What if we make cqfd run an alias to cqfd exec in 6.0 so people can still use cqfd run ?

Or is it better to force people stop using cqfd run ?

[gportay]

I would like to stop people using cqfd run and use cqfd shell or, even better, to use cqfd PROGRAM [ARGUMENTS...] that would be a better CLI in my opinion.

This is a breaking change, and this is the reason I suggest to bump to 6.0 (or 6) to highlight that bit change. Including the removal of comment ; and spaces around =, and the CQFD_DIR + -d to set an absolute path to the .cqfd/ directory. Also, the custom_img_name split to image and tag (or maybe docker_image and docker_tag).

The sudoization approach simplifies the code by removing the shell|exec|run code that is somehow cumbersome.

• cqfd run [PROGRAM] [ARGUMENTS...] -> cqfd [PROGRAM] [ARGUMENTS]
• cqfd run -c ARGUMENT -> cqfd -c "ARGUMENT"
• cqfd shell [ARGUMENTS] -> cqfd sh [ARGUMENTS]
• cqfd exec PROGRAM [ARGUMENTS] -> cqfd PROGRAM [ARGUMENTS]

So, there are two (three) invocations:

• cqfd to run command= set in .cqfdrc (run sh -c "$command")
• cqfd -c "ARGUMENTS" to concatenate the command= set in cqfdrc and run it (run sh -c "$command $opt_c").
• cqfd PROGRAM [PROGRAMS] to run the specified command PROGRAM [ARGUMENTS...] (run sh -c "${*@Q}").

Also, the former commands init and release are optionnized to --init and --release.

The little missing thing is: cqfd --init and cqfd --release would run command= and maybe the user does not expect to run it.
cqfd release currently run command=, but cqfd init does not.

Note: we can still keep a fatal message (or a workaround) in the cqfd_laucher to maintain temporarily the old fashion CLI, as long as there is no init, release or run binaries.

This kind of change could be performed later (a year or two), we could still think about it and make the changes whenever we are convinced it is a good evolution.

[florentsfl]

For --init it may be indeed good to leave it as cqfd init so it does not run the command=. But --release is good to optionize in my opinion.

Then, if we get rid of run|shell|exec, why not keep run as an optional keyword after cqfd to keep retrocompatibility ?

[gportay]

We may add a CQFD_COMPAT=56 environment for compatibility purpose, what do you think @florentsfl?

[florentsfl]

Ok in fact I would think that we can make a 5.7 release in the continuation of 5.6, without having deprecation warnings and --init option, and we’ll see after for a 6.0 release which may break things.

But I would not put deprecation warnings if we are not sure about what we will do in the future

[gportay]

Furthermore, you may consider having a 5.8 release before 6.0. Take you time, we are not in a hurry.

[gportay]

I have remaining nitpicks in #199.

Also, I would like to test the remaining untested call to cqfd in the tests.

I figured out one is failing that means the the test is certainly not running properly or is not written correctly.

I would make a PR by Monday.

Also, I have a change to fix commit 6dd7415.

[gportay]

@florentsfl, you can create milestones, and flag the PRs. I cannot create milestones myself and I think I won't be able to flag the PRs either.

[florentsfl]

I created the milestones

[gportay]

Thanks for the milestones. I think it is wise to have a 5.8 for serveral changes before 6.