mikey179 / releaseit Goto Github PK

Currently it is expected that any svn repository commands that involve communication with a server can be run without intercepting to ask the user for credentials. There should be a possibility to ask the user for credentials if required.

A user might want to sign the release, e.g. sign the commit with which the tag is created. This should be enabled by a flag or similar.

Sometimes you have a working directory which is not clean, but it's still ok to create a release - so you should be able to overrule the check with a --force flag.

It should be possible to supply a version number for the release via command line argument, so no questions will be asked by ReleaseIt.

I have a project which has references to external SVN repositories. In my case I refer to the trunk of the external repository.

Currently if I want to release the project, ReleaseIt shows me the following error:

Can't create release, working directory not clean.

ReleaseIt should support repositories with external references and should automatically freeze the current revision of all externals and create the tag. TortoiseSVN supports that when creating tags.

ReleaseIt might does something unexpected if the SVN URL contains /trunk before the actual trunk folder (e.g. https://svn.example.com/trunk-switcher/trunk).

With the example URL above the findTagsUrl method would return "https://svn.example.com/tags" instead of the expected "https://svn.example.com/trunk-switcher/tags" URL.

In order to be able to use ReleaseIt in an automated way there needs to be a flag --no-interaction which suppresses any confirmation questions. This also means ReleaseIt can't ask for a version number if there is no automated way to detect one - it should simply bail out with an error message then.

The git repository method getBranch() does not respect the currently selected branch but rather just returns the first one from all available branches. If the first one is not the current one the further logic will fail to suggest the correct version number for the release.

Currently, handling of prerelease version numbers like 1.0.0-beta is undefined and may result in wrongly calculated version numbers.

The library herrera-io/version currently used for version number validation is not maintained any more and thus should be replaced.

In case the local checkout where the release is created from is not on the same (e.g. latest) state as the remote repository there should be a warning so that the user can stop creating the release.