Development and Release Cycle Model

[heliocastro]

This is a proposal on how our development cycle should work regarding our development cycle.

First and all, the development cycle should be decoupled to the frontend UI, so one not prevents the other on evolve development.

• Release cycle in three stages:

  • Development Cycle
  • Feature Intermediary Cycle
  • Release Candidate and Publish Cycle

• Development cycle
  All updates come; if not, break the tests. If some functionality start to behave erratic, we fix or add a test for the fix. This is daily business. We update weekly on the patch level. You don't need to worry about the dates. It is not considered production level but should enable everyone to test faster and fix. We start to call it the "test release".

• Feature Cycle
  We update on the minor version level when a new feature is added with proper testing. You don't need to control dates, but the new features must have mandatory tests and be published when the FEATURE is considered stable, so everyone can test the feature without waiting for a release.
  If a new player comes to use SW360 and gets to have an implemented feature, they will not wait months until they have something usable to test.

• Release Candidate and Publish
  This date is marked on our expected release for the major version.
  NOW, this is serious business.
  We freeze the update of libraries EXCEPT for vulnerabilities.
  We freeze the features updates, and to simplify the job, EVERY bug in the issue list from the previous major release to the current release SHOULD be fixed.
  A constraint for this is we need to have all features planned included AND extra features added in the middle of cycle, as long the features follow the feature cycle above and have been appropriately tested.

Exception for release candidate freeze broke:

• Major vulnerability: Update, and fix no matter the consequences. Adjust the release date if necessary.
• Middle vulnerability: Test update, if validated, commit. If can't be faster validated, the decision on what to do goes to core team.
• Minor vulnerability: Only if not breaks compatibility, otherwise not be updated.
• New tests can be added.

[EttingerK]

@heliocastro thanks a lot for your process proposal.

I think it makes a lot of sense
I just would like to add in the Development Cycle:

• No change should be pushed withour a pull requests.
• Every pullrequest must be reviewed and approved by at least one other contributor.

These rules should added to the following pages when agreed on in the community:

https://eclipse.dev/sw360/docs/development/dev-dod-and-style/
https://eclipse.dev/sw360/docs/development/dev-releasing-sw360/

[heliocastro]

The changes are not automatic and we have a requirement to have at least one pull request since two weeks ago

[GMishx]

Created PR to update the SW360 guidelines as per the discussion here eclipse-sw360/sw360.website#63