Future frameworks releases

[Christian Mollekopf]

On Thu, Jun 11, 2015, at 08:56 PM, Sebastian Kügler wrote:
> On Tuesday, June 09, 2015 10:08:06 Christian Mollekopf wrote:
> > I'm sorry for the friction this causes right now, but in the long run I
> > really  don't see how this makes life harder for everyone else.
> 
> Here's an example from some recent packaging experiments. I wrote a
> script to 
> update the packages, with frameworks, it was a very easy thing, I change
> one 
> global version number, and I could check out a tag (same tag for every 
> framework) from git, then roll a tarball from those tags and build it. 
> Verifying that everything's OK was again a matter of checking the results 
> against one single version.
> 
> This process would have been a LOT more work with different version
> numbers, let alone some packages being excluded in certain releases, because all
> of a sudden, I'd have to keep track of all this manually.
> 

Getting the latest tag on master is entirely possible without knowing
the version number
(git describe --abbrev=0 --tags). Verifying that everything is ok indeed
would be
a bit more involved. So yes, it can get a bit more complex, but not a
whole lot really.

> Let's not forget that we're talking about a few hundred deployers here,
> and 
> perhaps a lot more we don't know about, and then hopefully a whole lot
> more in 
> the future. The consistency across frameworks at this basic project
> management 
> level just cannot be underestimated, and that's why I think that the
> proposal 
> of different versions, and different modules per release of frameworks is
> a /really bad idea/.

I absolutely agree with our point that we should keep things for
deployers as easy as possible,
and I think that is entirely possible with a reasonable amount of
effort.
I'm also very willing to propose solutions for problems that I'm made
aware of.

Cheers,
Christian