[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-release-team
Subject: Re: Future frameworks releases
From: Sebastian Kügler <sebas () kde ! org>
Date: 2015-06-17 5:21:33
Message-ID: 3418392.1hIWaGLrcR () monet
[Download RAW message or body]
On Tuesday, June 16, 2015 11:45:06 Christian Mollekopf wrote:
> 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.
It's possible, but it's cumbersome, involves more server roundtrips and
parsing, and is a lot harder to verify manually.
In the current model, it's as simple as
version = "5.11" for the setup (in my example script)
and
ls -l|grep -v 5.11
to verify that everything went well.
That's a simple and almost fail-safe solution.
> > 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/.
--
sebas
Sebastian Kügler | http://vizZzion.org | http://kde.org
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic