[Discussion] Release cycle for the repo

[gaiksaya]

Is your feature request related to a problem? Please describe

Define release cycle for this repo. The release will consist of cutting a tag for now.

Describe the solution you'd like

Open to approaches

Describe alternatives you've considered

No response

Additional context

No response

[gaiksaya]

One of the approaches that @prudhvigodithi suggested was

• Major Version: New shared libraries are added to the repo
• Minor Version: Fix Existing shared libraries
• Patch Version: CVE fixes, minor bug fixes, gradle changes not affecting any libraries, etc

@dblock @bbarani Would like your input here. Thanks!

[dblock]

You should follow semver.

• major = breaking changes; part of a PR for a breaking change, the PR increments major
• minor = new features; part of a PR for a new feature you increment minor instead
• patch = fixes; after a release you auto-increment patch

Release often.

[prudhvigodithi]

I'm ok with having major.minor.patch, but incrementing major would be comprehensive decision as here since jenkinsfile's uses libraries from git tags (which are already fixed), so there wont be anything as such called breaking changes (like we commit and push a new change and it will break the jenkins pipelines, this is not the case), every new fix made via a PR will only be inherited by jenkinsfiles with a new tag. So @dblock @gaiksaya any thoughts on how we categorize as a breaking change?

[gaiksaya]

Whatever breaks existing libraries can be categorized as breaking change. Example, take uploadMinSnapshotsToS3 library. So even if you change the path which might seem as a small change but change in artifact location can break a number of things. This can be considered as a breaking change.
PR author or maintainer needs to classify them accordingly.

[dblock]

+1 @gaiksaya in the PR the author/reviewer need to recognize that this is a breaking change, and if it is, also increment the major version as part of the PR