Open Stack

On 05/29/2015 07:14 PM, Haïkel wrote:
> 2015-05-29 15:41 GMT+02:00 Thierry Carrez <thierry at openstack.org>:
>> Hi everyone,
>>
>> TL;DR:
>> - We propose to stop tagging coordinated point releases (like 2015.1.1)
>> - We continue maintaining stable branches as a trusted source of stable
>> updates for all projects though
>>
> 
> Hi,
> 
> I'm one of the main maintainer of the packages for Fedora/RHEL/CentOS.
> We try to stick as much as possible to upstream (almost zero
> downstream patches),
> and without intermediate releases, it will get difficult.
> 
> I'm personally not fond of this as it will lead to more fragmentation.
> It may encourage
> bad behaviors like shipping downstream patches for bug fixes and CVE instead
> of collaborating upstream to differentiate themselves.
> For instance, if we had no point-based release, for issues tracking
> purposes, we would
> have to maintain our sets of tags somewhere.
> 
> There's also the release notes issue that has already been mentioned.
> Still continuous release notes won't solve the problem, as you wouldn't
> be able to map these to the actual packages. Will we require operators
> to find from which git commit, the packages were built and then try to figure
> out which fixes are and are not included?
>
>> (1) Projects do not all follow the same versioning, so some projects
>> (like Swift) were not part of the "stable point releases". More and more
>> projects are considering issuing intermediary releases (like Swift
>> does), like Ironic. That would result in a variety of version numbers,
>> and ultimately less and less projects being able to have a common
>> "2015.1.1"-like version.
>>
> 
> And that's actually a pain point to track for these releases in which
> OpenStack branch belong. And this is probably something that needs to
> be resolved.
> 
>> (2) Producing those costs a non-trivial amount of effort on a very small
>> team of volunteers, especially with projects caring about stable
>> branches in various amounts. We were constantly missing the
>> pre-announced dates on those ones. Looks like that effort could be
>> better spent improving the stable branches themselves and keeping them
>> working.
> 
> Agreed, but why not switching to a time-based release?
> Regularly, we tag/generate/upload tarballs, this could even be automated.
> As far as I'm concerned, I would be more happy to have more frequent releases.
> 
>> Now we realize that the cross-section of our community which was present
>> in that session might not fully represent the consumers of those
>> artifacts, which is why we expand the discussion on this mailing-list
>> (and soon on the operators ML).
> 
> Thanks, I was not able to join this discussion, and that was the kind
> of proposal that I was fearing to see happen.
> 
>> If you were a consumer of those and will miss them, please explain why.
>> In particular, please let us know how consuming that version (which was
>> only made available every n months) is significantly better than picking
>> your preferred time and get all the current stable branch HEADs at that
>> time.
> 
> We provide both type of builds
> * git continuous builds => for testing/CI and early feedback on potential issues
> * point-release based builds => for GA, and production
> 
> Anyway, I won't force anyone to do something they don't want to do but I'm
> willing to step in to keep point releases in one form or another.
> 
> Regards,
> H.

I fully agree with what Haikel wrote (and therefore wont repeat).

The same way, I didn't agree with the change of version scheme either.

Why not using something like: 201504.0.0, and allow projects to do
intermediate releases like 201506, 201507, etc? Or 20151 / 20152, and
then allow the middle number to increase as it pleases projects?
Basically, anything better than just random numbers?

Also, besides Ironic, which are the other projects that are willing to
release more often than 6 months?

Cheers,

Thomas