Finalize bases parser
Finalize OCI images Resources
Finalize craft-providers integration
Provide the building charms functionality through the pack command.
Enhanced charm template generated by ‘init’ to use the new sidecar-pattern
Support for oci-image resources.
Improvements to the ‘init’ command, among others: links to docs, more robust base project, better docstrings and comments.
Alert if README.md not included in a packed bundle (as it is required for deploying).
Produce a manifest.yaml with the building context of the charm or bundle.
Fix the handling of charms with dashes in the name when dealing with libraries.
Full support for Charm Bundles (register, upload, release, etc.); check the tutorial
Full support for file type Resources (upload, attach them to a charm release, etc.); check the tutorial
Point to external documentation in the docs left by init command
Renamed back to status the command to show channels and released revisions in Charmhub.
Show to the user the returned error in case of rejected upload.
Improved/updated the Bash Completion file according to current commands and their options.
Charmcraft works now with the PRODUCTION store by default (can be changed in the configuration).
Configuration is now read from the charmcraft.yaml file, which is mandatory for bundles-related commands (optional for the rest by now, will be mandatory in the future for all commands).
The User Agent sent to Charmhub is more complete and identifies better the Charmcraft client.
Added all current commands and their options to the Bash completion file.
Improvements in some help messages and init resulting files.
Added support for Charm Libraries, a mechanism to easily share and reuse charm interfaces and other components (tutorial)
Initial support for charm bundles: the ‘pack’ command.
Better project bootstrapping in ‘init’: can be used in a non-empty directory and adds coverage to the project tests.
Improved and polished texts, help and error messages, etc.
Support to create a library, first step in the charm libraries lifecycle.
Improved the template for new charms: now they use the testing harness in the modern way.
Refactored the commands infrastructure for improved process bootstrapping and UX consistency.
Small UX improvements in messages and help texts.
Include the version file in the built charm (to be used by Charmhub).
Now the revision is a mandatory parameter of the release command.
Refactored help messages and indications.
Better explanation in the README on how to run the project directly from Github.
Changed which files and directories are considered for a build: now everything is included in the charm, except what is explicitly marked as to ignore by Juju (which can be controlled through the .jujuignore file).
Improved commands structure: each now has a long description and accepts the --verbose and --quiet global options
Cope with conflicting command line arguments when using system pip3 from Ubuntu Bionic and earlier when building
Several improvements to charmcraft init, including --series and an improved README.
Support API changes in Store responses (old and new versions of a couple of renamed fields).
New ‘init’ command to populate an empty directory with the scaffolding for a new charm.
Basic but complete interaction with the Store, to authenticate, register and list names, and upload and release revisions (working with staging for now).
Commands and their options are autocompleted now (hitting tab, as usual).
Improvements when building charms: include the ‘template’ directory and support hooks that link the charm directly.
Clearer tracking of project version.
Charmcraft is now packaged as a snap (try it with snap install --edge charmcraft).
First interaction with the Store: now Charmcraft can authenticate against staging.
All debug information (what you would see in the terminal with --verbose) is now always sent to a log file (which is indicated if an error happens, and left there for forensics).
Improvements when the user interrupts the program (Ctrl-c) and in return codes in general.
Better debugging information when building a charm.
The zip filename now comes from metadata.yaml rather than the directory name.
A fix for #35, wherein we weren’t copying files into the charm.
Fixes an issue (#21) where we did the wrong thing for non-dispatch-aware jujus.
This is also 0.1.1 which we couldn’t release into pip due to human error.
supported commands: build, and version.
Charm Plugin for parts
Bundle Plugin for parts
Support for Teams & Collaborators
Adapt Charmcraft to the CLI Guidelines
Integrate with craft-store