Excerpts from Thierry Carrez's message of 2015-06-16 11:45:51 +0200:
> Doug Hellmann wrote:
> > [...]
> > I put together a little script [1] to try to count the previous
> > releases for projects, to use that as the basis for their first
> > SemVer-based version number. I pasted the output into an etherpad
> > [2] and started making notes about proposed release numbers at the
> > top. For now, I'm only working with the projects that have been
> > managed by the release team (have the "release:managed" tag in the
> > governance repository), but it should be easy enough for other projects
> > to use the same idea to pick a version number.
> 
> Your script missed 2015.1 tags for some reason...

They didn't match the pattern because they had a trailing digit, and I
didn't notice.

> I still think we should count the number of "integrated" releases
> instead of the number of releases (basically considering pre-integration
> releases as 0.x releases). That would give:

Hmm, OK, I didn't really consider them as pre-1.0 but I see your point.
I can go along with counting only integrated releases.

> ceilometer 5.0.0
> cinder 7.0.0
> glance 11.0.0
> heat 5.0.0
> horizon 8.0.0
> ironic 2.0.0
> keystone 8.0.0
> neutron* 7.0.0
> nova 12.0.0
> sahara 3.0.0
> trove 4.0.0
> 
> We also traditionally "managed" the previously-incubated projects. That
> would add the following to the mix:
> 
> barbican 1.0.0
> designate 1.0.0
> manila 1.0.0
> zaqar 1.0.0
> 

Those didn't have the release:managed tag, so didn't show up in the
output of the script. But I agree, if we're counting only from the
integrated releases then starting from 1.0 makes sense for those and any
other new projects that have joined the big tent during kilo.

Doug

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to