Re: Release Team BoF Summary
> On Monday, July 16, 2012 22:37:24 Michael Jansen wrote: > > > I do not like maskerading pre releases as stable version. Version > > > numbers have a > > > clear semantic meaning. And KDE currently breaks that. > > > > We break what? Our numbers have a clear sematic meaning, i can look at a > > version number and tell you what it is. Agreed it's not trivial, but saying > > our numbers don't have a semantinc meaning is not true. > > > > Cheers, > > Albert > > > > Any version numbered minor.major.patch is a stable release. That's what we > are breaking. Internally there must be a major, minor, and patchlevel number assigned and "4,5,71" is certainly more descriptive of what's going on programmatically than leaving it as something like "4,5,4" (and to parrot what dfaure has said, I've also seen code take good advantage of API added after an alpha release). If we want to call the corresponding "named version" (in git, tarball name, website, etc.) something like 4.6.0_alpha1 then that's fine and great and all but we can't dump text into our KDE version macros so we still must have a mapping for it. I see in your email from yesterday that you propose an automatically- maintained header-only increasing build number (which could possibly encompass snapshots as well)... is this internal-only build number really to keep the 'purity' of the internal-only patchlevel version? Because that really just seems like a needless change, especially given the large corps of people who are already quite familiar with existing KDE practice regarding internal version numbers. (P.S. Does anyone know how to configure KMail to reply to the plain-text version of an email instead of the HTML rich text version? :) Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
On 07/16/2012 05:41 PM, Rex Dieter wrote: On 07/16/2012 03:37 PM, Michael Jansen wrote: 4.5.70 is a stable release for anyone with experience in release numbers imo, that's a false assumption. anyone making that mistake deserves what they get. Hit enter too fast... I'm speaking mostly in terms if items that fall under the "kde development platform"(1) umbrella (or whatever you want to call it), so to be in the constructive mode and in case I missed it being suggested already, I would *not* mind tagging the tarballs to highlight the fact they are pre-releases, ie, kdefoo-4.5.70-beta1 As that preserves the ability to do strict numeric-only comparisions to be clear, what I do mind is stuff of the form: kdefoo-4.6-beta1 -- rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
Rex Dieter wrote: >On 07/16/2012 03:37 PM, Michael Jansen wrote: >> 4.5.70 is a stable release for anyone with experience in release >numbers > >imo, that's a false assumption. anyone making that mistake deserves >what they get. +1. I've seen ~near the next release number used for pre-release versions in enough other contexts that I didn't think it at all odd when I encountered it in KDE. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
On 07/16/2012 03:37 PM, Michael Jansen wrote: 4.5.70 is a stable release for anyone with experience in release numbers imo, that's a false assumption. anyone making that mistake deserves what they get. -- rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
El Dilluns, 16 de juliol de 2012, a les 23:37:12, Michael Jansen va escriure: > On Monday, July 16, 2012 10:42:11 PM Albert Astals Cid wrote: > > El Dilluns, 16 de juliol de 2012, a les 22:37:24, Michael Jansen va > > escriure: > > > > > I do not like maskerading pre releases as stable version. Version > > > > > numbers have a > > > > > clear semantic meaning. And KDE currently breaks that. > > > > > > > > We break what? Our numbers have a clear sematic meaning, i can look at > > > > a > > > > version number and tell you what it is. Agreed it's not trivial, but > > > > saying > > > > our numbers don't have a semantinc meaning is not true. > > > > > > > > Cheers, > > > > > > > > Albert > > > > > > Any version numbered minor.major.patch is a stable release. That's what > > > we > > > are breaking. > > > > > > 4.5.70 is a stable release for anyone with experience in release > > > numbers. > > > Yes with the background of doing kde developing you know its not. But > > > the > > > convention says it is. > > > > You mean like the gnome guys break it, and like the poppler guys break it, > > and like the kernel guys used to do? and that's without lookinf for > > examples. > > > > Your convention is too narrow minded. > > Ah. One of those. > > So when you see garbage on the street you throw yours out through the window > too? Because it is not wrong because others do it? If they stop you stop > too? silly comparison Cheers, Albert > > For me change for the better start with stuff i can change. So fixing kde > would be that first step. > > Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
On Monday, July 16, 2012 10:42:11 PM Albert Astals Cid wrote: > El Dilluns, 16 de juliol de 2012, a les 22:37:24, Michael Jansen va escriure: > > > > I do not like maskerading pre releases as stable version. Version > > > > numbers have a > > > > clear semantic meaning. And KDE currently breaks that. > > > > > > We break what? Our numbers have a clear sematic meaning, i can look at a > > > version number and tell you what it is. Agreed it's not trivial, but > > > saying > > > our numbers don't have a semantinc meaning is not true. > > > > > > Cheers, > > > > > > Albert > > > > Any version numbered minor.major.patch is a stable release. That's what we > > are breaking. > > > > 4.5.70 is a stable release for anyone with experience in release numbers. > > Yes with the background of doing kde developing you know its not. But the > > convention says it is. > > You mean like the gnome guys break it, and like the poppler guys break it, > and like the kernel guys used to do? and that's without lookinf for > examples. > > Your convention is too narrow minded. Ah. One of those. So when you see garbage on the street you throw yours out through the window too? Because it is not wrong because others do it? If they stop you stop too? For me change for the better start with stuff i can change. So fixing kde would be that first step. Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
El Dilluns, 16 de juliol de 2012, a les 22:37:24, Michael Jansen va escriure: > > > I do not like maskerading pre releases as stable version. Version > > > numbers have a > > > clear semantic meaning. And KDE currently breaks that. > > > > We break what? Our numbers have a clear sematic meaning, i can look at a > > version number and tell you what it is. Agreed it's not trivial, but > > saying > > our numbers don't have a semantinc meaning is not true. > > > > Cheers, > > > > Albert > > Any version numbered minor.major.patch is a stable release. That's what we > are breaking. > > 4.5.70 is a stable release for anyone with experience in release numbers. > Yes with the background of doing kde developing you know its not. But the > convention says it is. You mean like the gnome guys break it, and like the poppler guys break it, and like the kernel guys used to do? and that's without lookinf for examples. Your convention is too narrow minded. Cheers, Albert > > Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
> > I do not like maskerading pre releases as stable version. Version > > numbers have a > > clear semantic meaning. And KDE currently breaks that. > > We break what? Our numbers have a clear sematic meaning, i can look at a > version number and tell you what it is. Agreed it's not trivial, but saying > our numbers don't have a semantinc meaning is not true. > > Cheers, > Albert > Any version numbered minor.major.patch is a stable release. That's what we are breaking. 4.5.70 is a stable release for anyone with experience in release numbers. Yes with the background of doing kde developing you know its not. But the convention says it is. Mike___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
El Dilluns, 16 de juliol de 2012, a les 11:47:40, i...@michael-jansen.biz va escriure: > Am 2012-07-16 10:14, schrieb Aurélien Gâteau: > > Le dimanche 15 juillet 2012 16:39:54 Michael Jansen a écrit : > >> Let us postpone this until i have the script ready. I think the > >> discussion > >> is needed but currently a bit difficult because it is all really > >> theoritcal > >> now. > > > > It is all very theoritical because people took a simple and pragmatic > > proposal > > (do not change any macro, just use different values: 7x for alpha, 8x > > for beta > > and 9x for rc) and overengineered it. > > > > I am not sure what we are trying to solve there, it feels like an > > overkill. > > I do not like maskerading pre releases as stable version. Version > numbers have a > clear semantic meaning. And KDE currently breaks that. We break what? Our numbers have a clear sematic meaning, i can look at a version number and tell you what it is. Agreed it's not trivial, but saying our numbers don't have a semantinc meaning is not true. Cheers, Albert > > I will never do things in a way because it was always done that way if > there are clear > points showing it is wrong or not optimal. Especially if noone > remembers the reasons for > that or is able to come up with any guess why. And that is the > situation here. > > But if the dicussion here shows stuff gets to complicated otherwise i > have no problem > in not changing anything. But i need to discuss and brainstorm FIRST. > > AND i will document once and for all why we are doing things the way we > do. As a reference > for everyone who wonders. > > The other why. > > If i succeed in scripting the complete release process i would like to > setup weekly > snapshots. Because i consider them the "continuus integration" of the > release > process. > > Please tell me how those fit into the current scheme and we consider > it. > > Mike > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Changes to the kde-cvs-announce mailing list
On Monday 16 July 2012 13:11:56 Sebastian Kügler wrote: > On Sunday, July 15, 2012 22:20:13 David Faure wrote: > > Sysadmins are meta-moderators anyway (e.g. I can approve a mail on any > > mailing-list). > > So you have time left for emergency moderation? ;) Yes, this doesn't sound like a very time-consuming task :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Changes to the kde-cvs-announce mailing list
On Sunday, July 15, 2012 22:20:13 David Faure wrote: > Sysadmins are meta-moderators anyway (e.g. I can approve a mail on any > mailing-list). So you have time left for emergency moderation? ;) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
Am 2012-07-16 10:14, schrieb Aurélien Gâteau: Le dimanche 15 juillet 2012 16:39:54 Michael Jansen a écrit : Let us postpone this until i have the script ready. I think the discussion is needed but currently a bit difficult because it is all really theoritcal now. It is all very theoritical because people took a simple and pragmatic proposal (do not change any macro, just use different values: 7x for alpha, 8x for beta and 9x for rc) and overengineered it. I am not sure what we are trying to solve there, it feels like an overkill. I do not like maskerading pre releases as stable version. Version numbers have a clear semantic meaning. And KDE currently breaks that. I will never do things in a way because it was always done that way if there are clear points showing it is wrong or not optimal. Especially if noone remembers the reasons for that or is able to come up with any guess why. And that is the situation here. But if the dicussion here shows stuff gets to complicated otherwise i have no problem in not changing anything. But i need to discuss and brainstorm FIRST. AND i will document once and for all why we are doing things the way we do. As a reference for everyone who wonders. The other why. If i succeed in scripting the complete release process i would like to setup weekly snapshots. Because i consider them the "continuus integration" of the release process. Please tell me how those fit into the current scheme and we consider it. Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF Summary
Le dimanche 15 juillet 2012 16:39:54 Michael Jansen a écrit : > Let us postpone this until i have the script ready. I think the discussion > is needed but currently a bit difficult because it is all really theoritcal > now. It is all very theoritical because people took a simple and pragmatic proposal (do not change any macro, just use different values: 7x for alpha, 8x for beta and 9x for rc) and overengineered it. I am not sure what we are trying to solve there, it feels like an overkill. Aurélien ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
