Future frameworks releases
chrigi_1 at fastmail.fm
Tue Jun 16 09:45:06 UTC 2015
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
> 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
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,
> 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
> level just cannot be underestimated, and that's why I think that the
> 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
I'm also very willing to propose solutions for problems that I'm made
More information about the release-team