Repo structure and the upcoming 3.1 release.

With 3.1 pending release we should think some about the structure of the repo's and how we are going to handle the 3.1 release.and the retirement of the 3.0 builds. I think it would be bad to keep the 3.0 builds in the F16 folder. But I also don't think we should remove the folder either. This is the time to ask questions. 1) Do we want to make any changes to the layout? 2) How do we want to handle older versions? 3) Do want to keep the beta's around after the stable is moved to 3.1? For now I suggest we do the following. 1) After 3.1 is released we move the stable 3.0 F16 builds in to archive/3.0/f16 off the release folder. 2) Reserve Nightly for Jenkins builds of 3.2 3) clean out the 3.1 beta's Until we are ready to start testing 3.2 Does anyone else disagree with my idea's? Does anyone else have what the feel is a better plan? Thanks Robert

On 07/13/2012 06:50 PM, Robert Middleswarth wrote:
With 3.1 pending release we should think some about the structure of the repo's and how we are going to handle the 3.1 release.and the retirement of the 3.0 builds.
I think it would be bad to keep the 3.0 builds in the F16 folder. But I also don't think we should remove the folder either.
This is the time to ask questions.
1) Do we want to make any changes to the layout? 2) How do we want to handle older versions? 3) Do want to keep the beta's around after the stable is moved to 3.1?
For now I suggest we do the following.
1) After 3.1 is released we move the stable 3.0 F16 builds in to archive/3.0/f16 off the release folder. 2) Reserve Nightly for Jenkins builds of 3.2 3) clean out the 3.1 beta's Until we are ready to start testing 3.2
4) Create a soft link to the latest ovirt-release-x-x.noarch.rpm using the filename of fedora-ovirt-latest.rpm
Does anyone else disagree with my idea's?
Does anyone else have what the feel is a better plan?
Thanks Robert _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
participants (1)
-
Robert Middleswarth