Staged Releases
- Current release model
- Currently everything goes directly in main .
- Some exceptions for pre-releases, but that is not the norm. It is also orthogonal to this discussion.
- If the package is broken, this starts affecting people immediately.
- Options end up being to delete the package or not.
- Both choices are a total loss for one side.
- As a result, this quickly become contentious.
- This ends up being a lose-lose situation really and it is hard to get moving.
- It would be better if both parties could get something.
- One thought might be to relabel packages. ( conda forge/conda forge.github.io#181 )
- Still this is only happening after the fact which make it a bit undesirable.
- Other problematic cases include proposed changes that are controversial or difficult to test
- As they are controversial, the norm is to be timid and wait.
- This is detrimental for the community as it becomes unclear how to make progress.
- Further the conditions for resolving this are unclear.
- In the best case, it requires people build and test changes locally.
- In cases, where the features are not well tested. The same problems exist even if agreeable.
- One way forward here would make pre-releases available from PRs ( conda forge/conda forge.github.io#204 )
- Proposed staging model
- Packages go through a staging system.
- The purpose of the staging system are as follows.
- Improve stability in the conda-forge channel.
- Avoid contention that impedes development and/or results in unpleasant community debate.
- Allow developers a way to explore new features in a rapid development friendly manner.
- Allow stakeholders to explore package changes and provide better feedback.
- Developers of PRs get faster feedback through CI artifacts.
- Availability
- Not in the conda-forge channel
- Must get from the CIs.
- Artifact expiration? (CI determined)
- Artifact replacement? (CI determined)
- Storage concerns?
- Deployment
- AppVeyor has a [simple procedure]( https://www.appveyor.com/docs/packaging-artifacts ).
- CircleCI has a [simple procedure]( https://circleci.com/docs/build-artifacts/ ).
- TravisCI has a [procedure]( https://docs.travis-ci.com/user/uploading-artifacts/ ).
- They recently enabled this for all builds including open source. See this [blog entry]( https://blog.travis-ci.com/2016-05-03-caches-are-coming-to-everyone ).
- Target users
- PR developer
- Package maintainers.
- Interested third parties (i.e. end users).
- Potentially (though unlikely at this stage) downstream.
- Consequences
- Package is available for the PR developer to use.
- main is unaffected.
- Downloads from conda-forge generally are unaffected.
- Possible cost associated with S3 storage.
- Added to a label (i.e. test or test-<package name> ) under conda-forge
- Availability