On 4 May 2015 at 23:01, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2015-05-05 07:53:20 +1200 (+1200), Robert Collins wrote: > [...] >> release weekly > [...] > > I'm fine with releasing weekly when there's something to release, > but as PBR is somewhat stabilized and relatively tightly scoped I > _hope_ that we get to the point where we don't have bugs or new > features in PBR on a weekly basis. > > Cool with the rest of the proposal too.
Hey, As someone that did track master PBR Master for internal cross-project builds during the SemanticVersioning ping-pong, I have to agree that having a core tool that should be pretty static in feature deliverable be a regular blocker and instigator of build fails is a real pain. I am not sure that weekly builds provide much in the way of value, depending on the consumer of the library. The release cadence would be too short to really get value out of time base releases. Is it expected to assist openstack-infra in being able to plan upgrading? I can't see it helping distros or other vendors building derived versions of OpenStack? Would this mean that OpenStack projects would have to start caring about PBR, or can they expected the core pipelines to continue to work without knowledge of PBR's releases? What version(s) would stable/* be expected to use? For sake of argument, what does weekly provide that monthly doesn't? Or in the opposite direction - why would each commit not be treated as a release? As a consumer of PBR, I stopped tracking master because I was frustrated rebasing, and I had low confidence the next rebase wouldn't break my entire pipeline in hidden or subtle ways. The last change I made to PBR took 4 months to get approved, just idling as unreviewed. There is *nothing* more demotivating having a changeset blocked in this status, particularly when it is a simplistic change that is forcing you to use a derived version for internal usage causing additional cost of rebasing. So, what is happening with the project now to make reviews happen soon enough to make frequent time-based release useful? Perhaps it would be useful to spell out some of the API breaking changes you are planning? It feels to me that PBR should be pretty static in the near term... I am not convinced that frequent releases make API breaking changes easier, as I am not sure a core library like PBR can just support 1.0 and n-1 - so would each release keep support for pbr's major and minor? (PS. I really like PBR) -- Kind Regards, Dave Walker __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
