Re: Release Script (KF5)
Am Freitag, 27. Juli 2012, 22:03:48 schrieb Alexander Neundorf: > I think I mostly agree. It sounds like the correct thing to do. > I'm aware that this may somewhat contradict my posts to the versioning > discussions on kde-frameworks... > > But basically, if a library has not changed, I agree that it's version > number should also not change. > Still all can be released again, so you can get everything at once if you > need. > Then let's please get back to the important point: you will need to specify exactly "what fits together". Before the versioning starts to disagree. -- Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg D-93040 Regensburg Germany tel. +49 151 241 67748 (mobile) e-mail m...@akhuettel.de http://www.akhuettel.de/research/ http://www.physik.uni-r.de/forschung/huettel/ ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On Thursday 12 July 2012, Michael Jansen wrote: > On Thursday, July 12, 2012 07:21:40 PM Albert Astals Cid wrote: > > El Dijous, 12 de juliol de 2012, a les 13:26:12, David Faure va escriure: > > > On Wednesday 27 June 2012 17:21:28 Michael Jansen wrote: > > > > On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > > > > > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > > > > > If we really want to decouple our releases and be more flexible > > > > > > > with > > > > > > > doing > > > > > > > them i consider this change a requirement for any decision in > > > > > > > that regard. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Each and every module has to have its own version number build > > > > > > > in. I > > > > > > > guess > > > > > > > with the frameworks branch much of kdelibs already got that > > > > > > > change (no > > > > > > > idea > > > > > > > really, anyone with input?). But we have to do the same with > > > > > > > the rest > > > > > > > of > > > > > > > our modules. > > > > > > > > > > > > No idea about frameworks. David? Kevin? > > > > > > > > > > This is partly still under discussion. > > > > > > > > > > However the currently implemented solution is that each framework > > > > > has a > > > > > versions number, but that version number can be upgraded in all > > > > > frameworks > > > > > at the same time, using a script. > > > > > > > > > > A future framework on top of all others, could provide the version > > > > > number > > > > > for all apps, much like the current kdeversion.h. Basically it > > > > > would be > > > > > the > > > > > "SC" number, and not the version number of the libs themselves, as > > > > > is currently the case. > > > > > > > > But that SC number would be a lie. Because you only assume all > > > > modules are > > > > installed in the versions that were release as SC X.Y . You have no > > > > idea if > > > > the user or distro uses older or newer versions for some libraries, > > > > modules > > > > or apps. So that number has no information value. Perhaps some > > > > marketing value. But in bug reports it is useless. > > > > > > > > Do we release kdelibs as ONE package. Or do we plan to release many > > > > small > > > > packages? > > > > > > Many small packages, but all at the same time. So "based on KDE > > > Frameworks 5.0.1" will have some value in bug reports. > > > > > > However you're right, apps themselves should have their own version > > > number, > > > maybe we can solve the same way as we do for the frameworks: by running > > > a script that updates the toplevel CMakeLists.txt in all modules > > > before releasing. > > > > > > > If each library gets released standalone. What if whe make the kde sc > > > > release 4.10.7. I assume only 70% of all libraries got commits since > > > > 4.10.6 > > > > because stuff is pretty stable by now (7th update). Do we still > > > > release ALL > > > > libs or only those that got changed? > > > > > > All libs, obviously. Who would take the time to run a diff and make > > > really sure that nothing changed? This is additional work for nothing > > > and makes everything more complex. Just like right now, we release > > > kdeadmin or kdetoys with every KDE SC release, even if nothing > > > changed. > > > > > > > The same naturally goes for stuff like kdeedu now that it split. What > > > > if some application got no commits since the last minor release. > > > > Make a release anyway or skip it? For major releases i guess making > > > > a package anyway makes sense. Or not? > > > > > > I can't decide there, that's for the release team to decide, but IMHO > > > if it's all scripted and done all at once (KDE SC release), then it's > > > simpler to just re-release everything. > > > > I agree with David here, just release everything, it's easier for > > everyone. > > No it is not. It is a waste of bandwidth, resources and time for all > involved. > > Do you really think forcing an update of unchanged modules for our > convenience will help those of us trying to use plasma for mobile devices? > > Do you really think splitting up kdelibs and then releasing it more or less > as one big blog is really helpful? Will it help people consider kde a more > lightweight dependency? > > I will implement the ability to skip release for unchanged modules (fully > automated) and would ask everyone here to really think twice before asking > the release team to keep the current practice of releasing everything. I think I mostly agree. It sounds like the correct thing to do. I'm aware that this may somewhat contradict my posts to the versioning discussions on kde-frameworks... But basically, if a library has not changed, I agree that it's version number should also not change. Still all can be released again, so you can get everything at once if you need. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/rel
Re: Release Script (KF5)
Hi, On Wednesday, July 18, 2012 13:25:55 i...@michael-jansen.biz wrote: > >> This will hurt the plasma mobile effort. > > > > FWIW, that assumption is wrong: Having version numbers be in line > > with each > > other makes our work easier, because we can just check if all > > packages are at > > least at version X.Y.Z and don't need special knowledge about which > > packages > > did indeed have commits in a certain period. > > > > That's no different from normal distribution. > > So you consider it less work to repackage 60 modules instead of 12? > > You consider it less strain on your servers and users bandwidth to send > them 60 repackaged modules instead of 12? > > Really? Yes. Especially, if the chance is really low that a package did not change at all. I've explained our *current* version numbering so many times that an even more complex one is just quadrupling the trouble, making it much more likely to have outdated packages and not notice them. A common version number provides great value. Cheers, -- 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: Re: Release Script (KF5)
Am 2012-07-18 12:01, schrieb Sebastian Kügler: On Thursday, July 12, 2012 20:00:27 Michael Jansen wrote: > > Do you really think forcing an update of unchanged modules for our > > convenience will help those of us trying to use plasma for mobile > > devices? > > That's the work of the distributor for those mobile devices. Exactly as i said. For our convenience we put the work on their shoulders. This will hurt the plasma mobile effort. FWIW, that assumption is wrong: Having version numbers be in line with each other makes our work easier, because we can just check if all packages are at least at version X.Y.Z and don't need special knowledge about which packages did indeed have commits in a certain period. That's no different from normal distribution. So you consider it less work to repackage 60 modules instead of 12? You consider it less strain on your servers and users bandwidth to send them 60 repackaged modules instead of 12? Really? Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Release Script (KF5)
On Thursday, July 12, 2012 20:00:27 Michael Jansen wrote: > > > Do you really think forcing an update of unchanged modules for our > > > convenience will help those of us trying to use plasma for mobile > > > devices? > > > > That's the work of the distributor for those mobile devices. > > > Exactly as i said. For our convenience we put the work on their shoulders. > This will hurt the plasma mobile effort. FWIW, that assumption is wrong: Having version numbers be in line with each other makes our work easier, because we can just check if all packages are at least at version X.Y.Z and don't need special knowledge about which packages did indeed have commits in a certain period. That's no different from normal distribution. -- 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 Script (KF5)
On 2012-07-12, Martin Gräßlin wrote: > My understanding is that there won't be a kde-runtime once there is=20 > frameworks. Correct. Runtime bits go to the libs that has them as a implementation detail. /Sune ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On Thursday, July 12, 2012 09:30:51 PM Michael Jansen wrote: > > The one real world experience we have with this is kdepim. From my > > perspective as a packager the entire transition has been a disaster and > > created huge work for us (shortly before our KDE 4.7 based release I was > > doing almost commit by commit updates of our packages in the hopes of > > getting users something better). Additionally, there was confusion about > > what versions of kdepim/-runtime/pimlibs could be combined in the interim. > > There were third digit updates that only worked with certain KDE SC > > versions. It was a mess. > > > > In theory it may not be more work, but so far in practice it's been hugely > > so. > > So to reiterate what i think i said somewhere else. This is not going to > happen with 4.9, This is possibly going to happen with 4.10 or 5.0. > > This will happen after it is ready and we take the input here serious. > > And ready is defined by consensus on this list. Great. I think that the discussion would go better if people wouldn't assume the knew what the impact of something on everyone else was or that if you aren't packaging KDE for a distribution you understand how easy/hard that is and how changes affect it. I look forward to the discussion. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
> The one real world experience we have with this is kdepim. From my > perspective as a packager the entire transition has been a disaster and > created huge work for us (shortly before our KDE 4.7 based release I was > doing almost commit by commit updates of our packages in the hopes of > getting users something better). Additionally, there was confusion about > what versions of kdepim/-runtime/pimlibs could be combined in the interim. > There were third digit updates that only worked with certain KDE SC > versions. It was a mess. > > In theory it may not be more work, but so far in practice it's been hugely > so. So to reiterate what i think i said somewhere else. This is not going to happen with 4.9, This is possibly going to happen with 4.10 or 5.0. This will happen after it is ready and we take the input here serious. And ready is defined by consensus on this list. Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Release Script (KF5)
On Thursday 12 July 2012 13:36:18 Rex Dieter wrote: > On 07/12/2012 01:25 PM, Martin Gräßlin wrote: > > But apart from that: could we start dreaming? Dreaming of a KDE where > > every > > application clearly defines what dependencies it has and exactly in a way > > that packagers can set up the dependencies in an automatic and correct > > way? Can we consider going forward with leaving all hacks behind us and > > not stop the fixing with the hacks being the reasons? > > Yes, please. My dream includes: > > start the work to define this wonderfully well-specified set of > dependencies *first*, *then* consider dropping all the old assumptions > and hacks (not before). I think we are currently in the process of doing just that. Currently no hacks are dropped yet and we plan for the future. What I got from this thread is that we as KDE developers have to define more clearly our dependencies. So in this process of evaluating what we need for the future, the current hacks have to be irrelevant as that will just mean we will never have a bright future in that regard. Of course we have to keep the hacks as a plan B in case plan A (getting it right) does not work out :-) Cheers Martin 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 Script (KF5)
On Thursday, July 12, 2012 07:48:53 PM Martin Gräßlin wrote: > On Thursday 12 July 2012 19:43:54 Martin Gräßlin wrote: > > So you will have a one-time task to set up the distribution build system > > to > > create these packages. What I do not understand is why having particular > > frameworks skip a release would make your work easier. > > logic error: s/easier/more difficult/g The one real world experience we have with this is kdepim. From my perspective as a packager the entire transition has been a disaster and created huge work for us (shortly before our KDE 4.7 based release I was doing almost commit by commit updates of our packages in the hopes of getting users something better). Additionally, there was confusion about what versions of kdepim/-runtime/pimlibs could be combined in the interim. There were third digit updates that only worked with certain KDE SC versions. It was a mess. In theory it may not be more work, but so far in practice it's been hugely so. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On Thursday, July 12, 2012 10:50:01 AM Albert Astals Cid wrote: > > Do you really think forcing an update of unchanged modules for our > > convenience will help those of us trying to use plasma for mobile devices? > > That's the work of the distributor for those mobile devices. I think you're missing his point (at least as I understood it). The primary issue isn't if it's more are less work for the distributor, but the number of upgrades users have to deal with if you update everything to chase a version number. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
> > You declare your dependencies ( A >= 4.3, B >= 4.5, C>=1.7 ) > B declares ( C >= 1.6,!1.7) (Because of some 1.7 bug) G.. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On Thursday, July 12, 2012 08:25:03 PM Martin Gräßlin wrote: > On Thursday 12 July 2012 13:01:47 Rex Dieter wrote: > > On 07/12/2012 12:43 PM, Martin Gräßlin wrote: > > >> Now, I'd have a much lesser concern if modules that are part of the > > >> 'kde > > >> development platform' at least are never skipped. > > > > > > Could you explain why? > > > > So, right now I can do a very simple runtime dependency for kde apps: > > > > KDE_DEV_VERSION=$(kde4-config --kde-version | cut -d' ' -f1) > > > > Requires: kde-runtime >= $KDE_DEV_VERSION > > My understanding is that there won't be a kde-runtime once there is > frameworks. > > But apart from that: could we start dreaming? Dreaming of a KDE where every > application clearly defines what dependencies it has and exactly in a way > that packagers can set up the dependencies in an automatic and correct way? > Can we consider going forward with leaving all hacks behind us and not stop > the fixing with the hacks being the reasons? > > For me as a developer it would be much nicer if I could say that my app > requires only version 5.x of framework bar and 5.y of framework foobar. And > not having a generic dependency set by the packager to 5.z. > > Would that change your point of view? Would it still be more difficult or in > fact easier? We both know i am totally with you. But let me play devils advocate here. Maven is most sophisticated framework so far that tries to deal with dependencies. But instead of solving the problem they just changed their problems. The problem i call the maven dependency hell. You declare your dependencies ( A >= 4.3, B >= 4.5 ) B declares ( C >= 1.6,!1.7) (Because of some 1.7 bug) And 1.7 is the latest version the problems begin. Splitting has its short- comings. And in case of maven you will often have more than 3 version of some dependencies dependency involved in your build. It mostly happends while they build and download dependencies for the current project, skip to the next project only to notice this one needs a newer version of the dependeny. So we have to make sure we don't get there. We have to get much better in declaring the dependies and KEEEPING binary and source compatibility. And we still have to think of all our little packages as a part from the big package kde. Which means we should setup a global list of dependencies and the current version we depend on. And everyone has to adhere to the list. I mean mainly what currently is kdelibs, kdebase. Even if we split there we still have to consider it as one unit that is released independently. Changes to the list should have a formalized process. Ask for change, discussion, decision here. Apps can do what they want. I am willing to work on that stuff. Gimme some time. Mike___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On 07/12/2012 01:25 PM, Martin Gräßlin wrote: But apart from that: could we start dreaming? Dreaming of a KDE where every application clearly defines what dependencies it has and exactly in a way that packagers can set up the dependencies in an automatic and correct way? Can we consider going forward with leaving all hacks behind us and not stop the fixing with the hacks being the reasons? Yes, please. My dream includes: start the work to define this wonderfully well-specified set of dependencies *first*, *then* consider dropping all the old assumptions and hacks (not before). -- rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Release Script (KF5)
On Thursday 12 July 2012 13:01:47 Rex Dieter wrote: > On 07/12/2012 12:43 PM, Martin Gräßlin wrote: > >> Now, I'd have a much lesser concern if modules that are part of the 'kde > >> development platform' at least are never skipped. > > > > Could you explain why? > > So, right now I can do a very simple runtime dependency for kde apps: > > KDE_DEV_VERSION=$(kde4-config --kde-version | cut -d' ' -f1) > > Requires: kde-runtime >= $KDE_DEV_VERSION My understanding is that there won't be a kde-runtime once there is frameworks. But apart from that: could we start dreaming? Dreaming of a KDE where every application clearly defines what dependencies it has and exactly in a way that packagers can set up the dependencies in an automatic and correct way? Can we consider going forward with leaving all hacks behind us and not stop the fixing with the hacks being the reasons? For me as a developer it would be much nicer if I could say that my app requires only version 5.x of framework bar and 5.y of framework foobar. And not having a generic dependency set by the packager to 5.z. Would that change your point of view? Would it still be more difficult or in fact easier? Kind Regards Martin Gräßlin 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 Script (KF5)
> > > I agree with David here, just release everything, it's easier for > > > everyone. > > > > No it is not. It is a waste of bandwidth, resources and time for all > > involved. > > Why do you ask for opinions of you are in possession of the truth? I do not understand why you are saying that. > > > Do you really think forcing an update of unchanged modules for our > > convenience will help those of us trying to use plasma for mobile devices? > > That's the work of the distributor for those mobile devices. Exactly as i said. For our convenience we put the work on their shoulders. This will hurt the plasma mobile effort. > > I will implement the ability to skip release for unchanged modules (fully > > automated) and would ask everyone here to really think twice before asking > > the release team to keep the current practice of releasing everything. > > Because there is no reason. Implementing the ability does not mean it has to be done like that. That is not my decision. It will be configurable. The decision is for this list. > Please, next time there is no reason for something, just do it, don't ask > people involved, complain they don't answer, and when they answer ignore > them anyway. > > Cheers, > Albert > > P.S: Is that blunt enough for you? No. But you understood me wrong. The word ability does not mean it has to be used. So i can't see what gave you the impression i decided for all of us. Still i have no problem with your email. Mike___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On 07/12/2012 12:43 PM, Martin Gräßlin wrote: Now, I'd have a much lesser concern if modules that are part of the 'kde development platform' at least are never skipped. Could you explain why? So, right now I can do a very simple runtime dependency for kde apps: KDE_DEV_VERSION=$(kde4-config --kde-version | cut -d' ' -f1) Requires: kde-runtime >= $KDE_DEV_VERSION to ensure that this application pulls in (at least) the version of kde "stuff" used to build it. (and kde-runtime in turn has versioned dependencies on stuff lower than itself in the stack, like kdelibs, kdepimlibs, oxygen-icons, nepomuk-core). An analogue for libraries where the above is simplified to just Requires: kdelibs >= $KDE_DEV_VERSION Which happens to work quite nicely now in practice.(1) Now, this will get much more complicated to track if the 'kde development platform' is no longer released as a whole and versions don't match up. This, at least from my own POV, is where requests from packagers are coming that module inter-dependencies (esp versioning!) be clearly documented somewhere. A lot of this could go away of qt/kde actually used symbol versioning too, but I digress... :( -- rex (1) A lot of this could go away if qt/kde actually used symbol versioning too, but I digress... :( ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
El Dijous, 12 de juliol de 2012, a les 19:29:46, Michael Jansen va escriure: > On Thursday, July 12, 2012 07:21:40 PM Albert Astals Cid wrote: > > El Dijous, 12 de juliol de 2012, a les 13:26:12, David Faure va escriure: > > > On Wednesday 27 June 2012 17:21:28 Michael Jansen wrote: > > > > On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > > > > > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > > > > > If we really want to decouple our releases and be more flexible > > > > > > > with > > > > > > > doing > > > > > > > them i consider this change a requirement for any decision in > > > > > > > that > > > > > > > regard. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Each and every module has to have its own version number build > > > > > > > in. > > > > > > > I > > > > > > > guess > > > > > > > with the frameworks branch much of kdelibs already got that > > > > > > > change > > > > > > > (no > > > > > > > idea > > > > > > > really, anyone with input?). But we have to do the same with the > > > > > > > rest > > > > > > > of > > > > > > > our modules. > > > > > > > > > > > > No idea about frameworks. David? Kevin? > > > > > > > > > > This is partly still under discussion. > > > > > > > > > > However the currently implemented solution is that each framework > > > > > has > > > > > a > > > > > versions number, but that version number can be upgraded in all > > > > > frameworks > > > > > at the same time, using a script. > > > > > > > > > > A future framework on top of all others, could provide the version > > > > > number > > > > > for all apps, much like the current kdeversion.h. Basically it would > > > > > be > > > > > the > > > > > "SC" number, and not the version number of the libs themselves, as > > > > > is > > > > > currently the case. > > > > > > > > But that SC number would be a lie. Because you only assume all modules > > > > are > > > > installed in the versions that were release as SC X.Y . You have no > > > > idea > > > > if > > > > the user or distro uses older or newer versions for some libraries, > > > > modules > > > > or apps. So that number has no information value. Perhaps some > > > > marketing > > > > value. But in bug reports it is useless. > > > > > > > > Do we release kdelibs as ONE package. Or do we plan to release many > > > > small > > > > packages? > > > > > > Many small packages, but all at the same time. So "based on KDE > > > Frameworks > > > 5.0.1" will have some value in bug reports. > > > > > > However you're right, apps themselves should have their own version > > > number, > > > maybe we can solve the same way as we do for the frameworks: by running > > > a > > > script that updates the toplevel CMakeLists.txt in all modules before > > > releasing. > > > > > > > If each library gets released standalone. What if whe make the kde sc > > > > release 4.10.7. I assume only 70% of all libraries got commits since > > > > 4.10.6 > > > > because stuff is pretty stable by now (7th update). Do we still > > > > release > > > > ALL > > > > libs or only those that got changed? > > > > > > All libs, obviously. Who would take the time to run a diff and make > > > really > > > sure that nothing changed? This is additional work for nothing and makes > > > everything more complex. Just like right now, we release kdeadmin or > > > kdetoys with every KDE SC release, even if nothing changed. > > > > > > > The same naturally goes for stuff like kdeedu now that it split. What > > > > if > > > > some application got no commits since the last minor release. Make a > > > > release anyway or skip it? For major releases i guess making a package > > > > anyway makes sense. Or not? > > > > > > I can't decide there, that's for the release team to decide, but IMHO if > > > it's all scripted and done all at once (KDE SC release), then it's > > > simpler > > > to just re-release everything. > > > > I agree with David here, just release everything, it's easier for > > everyone. > > No it is not. It is a waste of bandwidth, resources and time for all > involved. Why do you ask for opinions of you are in possession of the truth? > Do you really think forcing an update of unchanged modules for our > convenience will help those of us trying to use plasma for mobile devices? That's the work of the distributor for those mobile devices. > Do you really think splitting up kdelibs and then releasing it more or less > as one big blog is really helpful? David thinks it is. I agree with him. > Will it help people consider kde a more lightweight dependency? Can't read people's minds. > I will implement the ability to skip release for unchanged modules (fully > automated) and would ask everyone here to really think twice before asking > the release team to keep the current practice of releasing everything. > Because there is no reason. Please, next time there is no reason for something, just do it, don't ask people involved, complain they don't answer, and when the
Re: Re: Re: Release Script (KF5)
On Thursday 12 July 2012 19:43:54 Martin Gräßlin wrote: > So you will have a one-time task to set up the distribution build system to > create these packages. What I do not understand is why having particular > frameworks skip a release would make your work easier. logic error: s/easier/more difficult/g 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: Re: Release Script (KF5)
On Thursday 12 July 2012 12:36:05 Rex Dieter wrote: > On 07/12/2012 12:29 PM, Michael Jansen wrote: > > I will implement the ability to skip release for unchanged modules > > (fully automated) and would ask everyone here to really think twice > > before asking the release team to keep the current practice of releasing > > everything. Because there is no reason. > > Not exactly no reason. There's the case that it can be used to simplify > versioning on pkg interdependencies. > > Now, I'd have a much lesser concern if modules that are part of the 'kde > development platform' at least are never skipped. Could you explain why? As far as I understand moving to frameworks 5 will mean for packagers that what used to be one package (kdelibs) will be turned into something like 20 individual packages (I hope no distribution will continue to bundle all frameworks in one package as that would kind of destroy the idea of frameworks). So you will have a one-time task to set up the distribution build system to create these packages. What I do not understand is why having particular frameworks skip a release would make your work easier. I would imagine that you have some script magic going on to automate the package building once a release is done and that script should easily be able to detect that there has not been a new release for a given framework. Yes, No? Kind Regards Martin Gräßlin Who will probably have to maintain a small framework which will perhaps be updated once a years. 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 Script (KF5)
On 07/12/2012 12:29 PM, Michael Jansen wrote: I will implement the ability to skip release for unchanged modules (fully automated) and would ask everyone here to really think twice before asking the release team to keep the current practice of releasing everything. Because there is no reason. Not exactly no reason. There's the case that it can be used to simplify versioning on pkg interdependencies. Now, I'd have a much lesser concern if modules that are part of the 'kde development platform' at least are never skipped. -- rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On Thursday, July 12, 2012 07:21:40 PM Albert Astals Cid wrote: > El Dijous, 12 de juliol de 2012, a les 13:26:12, David Faure va escriure: > > On Wednesday 27 June 2012 17:21:28 Michael Jansen wrote: > > > On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > > > > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > > > > If we really want to decouple our releases and be more flexible > > > > > > with > > > > > > doing > > > > > > them i consider this change a requirement for any decision in that > > > > > > regard. > > > > > > > > > > > > > > > > > > > > > > > > Each and every module has to have its own version number build in. > > > > > > I > > > > > > guess > > > > > > with the frameworks branch much of kdelibs already got that change > > > > > > (no > > > > > > idea > > > > > > really, anyone with input?). But we have to do the same with the > > > > > > rest > > > > > > of > > > > > > our modules. > > > > > > > > > > No idea about frameworks. David? Kevin? > > > > > > > > This is partly still under discussion. > > > > > > > > However the currently implemented solution is that each framework has > > > > a > > > > versions number, but that version number can be upgraded in all > > > > frameworks > > > > at the same time, using a script. > > > > > > > > A future framework on top of all others, could provide the version > > > > number > > > > for all apps, much like the current kdeversion.h. Basically it would > > > > be > > > > the > > > > "SC" number, and not the version number of the libs themselves, as is > > > > currently the case. > > > > > > But that SC number would be a lie. Because you only assume all modules > > > are > > > installed in the versions that were release as SC X.Y . You have no idea > > > if > > > the user or distro uses older or newer versions for some libraries, > > > modules > > > or apps. So that number has no information value. Perhaps some marketing > > > value. But in bug reports it is useless. > > > > > > Do we release kdelibs as ONE package. Or do we plan to release many > > > small > > > packages? > > > > Many small packages, but all at the same time. So "based on KDE Frameworks > > 5.0.1" will have some value in bug reports. > > > > However you're right, apps themselves should have their own version > > number, > > maybe we can solve the same way as we do for the frameworks: by running a > > script that updates the toplevel CMakeLists.txt in all modules before > > releasing. > > > > > If each library gets released standalone. What if whe make the kde sc > > > release 4.10.7. I assume only 70% of all libraries got commits since > > > 4.10.6 > > > because stuff is pretty stable by now (7th update). Do we still release > > > ALL > > > libs or only those that got changed? > > > > All libs, obviously. Who would take the time to run a diff and make really > > sure that nothing changed? This is additional work for nothing and makes > > everything more complex. Just like right now, we release kdeadmin or > > kdetoys with every KDE SC release, even if nothing changed. > > > > > The same naturally goes for stuff like kdeedu now that it split. What if > > > some application got no commits since the last minor release. Make a > > > release anyway or skip it? For major releases i guess making a package > > > anyway makes sense. Or not? > > > > I can't decide there, that's for the release team to decide, but IMHO if > > it's all scripted and done all at once (KDE SC release), then it's simpler > > to just re-release everything. > > I agree with David here, just release everything, it's easier for everyone. No it is not. It is a waste of bandwidth, resources and time for all involved. Do you really think forcing an update of unchanged modules for our convenience will help those of us trying to use plasma for mobile devices? Do you really think splitting up kdelibs and then releasing it more or less as one big blog is really helpful? Will it help people consider kde a more lightweight dependency? I will implement the ability to skip release for unchanged modules (fully automated) and would ask everyone here to really think twice before asking the release team to keep the current practice of releasing everything. Because there is no reason. Mike > > Cheers, > Albert > > ___ > Kde-buildsystem mailing list > kde-buildsys...@kde.org > https://mail.kde.org/mailman/listinfo/kde-buildsystem -- Michael Jansen http://michael-jansen.biz___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
El Dijous, 12 de juliol de 2012, a les 13:26:12, David Faure va escriure: > On Wednesday 27 June 2012 17:21:28 Michael Jansen wrote: > > On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > > > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > > > If we really want to decouple our releases and be more flexible with > > > > > doing > > > > > them i consider this change a requirement for any decision in that > > > > > regard. > > > > > > > > > > > > > > > > > > > > Each and every module has to have its own version number build in. I > > > > > guess > > > > > with the frameworks branch much of kdelibs already got that change > > > > > (no > > > > > idea > > > > > really, anyone with input?). But we have to do the same with the > > > > > rest > > > > > of > > > > > our modules. > > > > > > > > No idea about frameworks. David? Kevin? > > > > > > This is partly still under discussion. > > > > > > However the currently implemented solution is that each framework has a > > > versions number, but that version number can be upgraded in all > > > frameworks > > > at the same time, using a script. > > > > > > A future framework on top of all others, could provide the version > > > number > > > for all apps, much like the current kdeversion.h. Basically it would be > > > the > > > "SC" number, and not the version number of the libs themselves, as is > > > currently the case. > > > > But that SC number would be a lie. Because you only assume all modules are > > installed in the versions that were release as SC X.Y . You have no idea > > if > > the user or distro uses older or newer versions for some libraries, > > modules > > or apps. So that number has no information value. Perhaps some marketing > > value. But in bug reports it is useless. > > > > Do we release kdelibs as ONE package. Or do we plan to release many small > > packages? > > Many small packages, but all at the same time. So "based on KDE Frameworks > 5.0.1" will have some value in bug reports. > > However you're right, apps themselves should have their own version number, > maybe we can solve the same way as we do for the frameworks: by running a > script that updates the toplevel CMakeLists.txt in all modules before > releasing. > > > If each library gets released standalone. What if whe make the kde sc > > release 4.10.7. I assume only 70% of all libraries got commits since > > 4.10.6 > > because stuff is pretty stable by now (7th update). Do we still release > > ALL > > libs or only those that got changed? > > All libs, obviously. Who would take the time to run a diff and make really > sure that nothing changed? This is additional work for nothing and makes > everything more complex. Just like right now, we release kdeadmin or > kdetoys with every KDE SC release, even if nothing changed. > > > The same naturally goes for stuff like kdeedu now that it split. What if > > some application got no commits since the last minor release. Make a > > release anyway or skip it? For major releases i guess making a package > > anyway makes sense. Or not? > > I can't decide there, that's for the release team to decide, but IMHO if > it's all scripted and done all at once (KDE SC release), then it's simpler > to just re-release everything. I agree with David here, just release everything, it's easier for everyone. Cheers, Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script (KF5)
On Wednesday 27 June 2012 17:21:28 Michael Jansen wrote: > On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > > If we really want to decouple our releases and be more flexible with > > > > doing > > > > them i consider this change a requirement for any decision in that > > > > regard. > > > > > > > > > > > > > > > > Each and every module has to have its own version number build in. I > > > > guess > > > > with the frameworks branch much of kdelibs already got that change (no > > > > idea > > > > really, anyone with input?). But we have to do the same with the rest > > > > of > > > > our modules. > > > > > > No idea about frameworks. David? Kevin? > > > > This is partly still under discussion. > > > > However the currently implemented solution is that each framework has a > > versions number, but that version number can be upgraded in all frameworks > > at the same time, using a script. > > > > A future framework on top of all others, could provide the version number > > for all apps, much like the current kdeversion.h. Basically it would be > > the > > "SC" number, and not the version number of the libs themselves, as is > > currently the case. > > But that SC number would be a lie. Because you only assume all modules are > installed in the versions that were release as SC X.Y . You have no idea if > the user or distro uses older or newer versions for some libraries, modules > or apps. So that number has no information value. Perhaps some marketing > value. But in bug reports it is useless. > > Do we release kdelibs as ONE package. Or do we plan to release many small > packages? Many small packages, but all at the same time. So "based on KDE Frameworks 5.0.1" will have some value in bug reports. However you're right, apps themselves should have their own version number, maybe we can solve the same way as we do for the frameworks: by running a script that updates the toplevel CMakeLists.txt in all modules before releasing. > If each library gets released standalone. What if whe make the kde sc > release 4.10.7. I assume only 70% of all libraries got commits since 4.10.6 > because stuff is pretty stable by now (7th update). Do we still release ALL > libs or only those that got changed? All libs, obviously. Who would take the time to run a diff and make really sure that nothing changed? This is additional work for nothing and makes everything more complex. Just like right now, we release kdeadmin or kdetoys with every KDE SC release, even if nothing changed. > The same naturally goes for stuff like kdeedu now that it split. What if > some application got no commits since the last minor release. Make a > release anyway or skip it? For major releases i guess making a package > anyway makes sense. Or not? I can't decide there, that's for the release team to decide, but IMHO if it's all scripted and done all at once (KDE SC release), then it's simpler to just re-release everything. -- 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: Release Script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08-07-2012 01:56, Michael Pyne wrote: >> On Sunday, July 08, 2012 02:30:13 Michael Jansen wrote: >>> Gentoo already supports betas, RCs, etc. in Portage though they >>> have a different nomenclature (e.g. I think 4.7.0~beta1 would >>> be 4.7.0_beta1 in Portage). But in order to support generic KDE >>> snapshots that nomenclature shouldn't change too much across >>> future releases. As long as it's mostly > set >>> one time it shouldn't be hard to generically rewrite KDE >>> versions into > what >>> is used by Gentoo (or rather, rewrite the Gentoo version to the >>> KDE > version >>> to find the tarball!). >>> >>> All the rest is administrivia in my opinion for a packager >>> (they can rely > on >>> a good-enough GNU tar since they can enforce its presence). I >>> would just make sure that the only versioning info in >>> *released* snapshot tarballs > and >>> directories is the version itself (i.e. no dates, no revision >>> tags or commit ids). >> >> What is the version of a snapshot? Give an example. For me it is >> the date. > What do you expect it to be? Just snapshot? Keep the misuse of > stable version numbers? > > For a beta or RC, just use that version tag with no date (e.g. > kdelibs-4.9.0~rc1). There would be no symlink to this as it's a > real "release", not a snapshot. For the extracted directory name I > would include the version name as that seems to be the standard > style (I do that with my own software releases at least). I like the current use of >= X.7.50 to denote versions leading to a proper release (X.Y+1.0). But if you want to change that, in Gentoo we support alpha, beta, pre (pre-release), rc (release candidate) and p (patch) versions. > For a routine nightly snapshot, use the date as the version, with a > symlink to that module on the FTP server. The symlink name should > mention that it's a snapshot of some sort (e.g. kdelibs-git.tar.bz2 > -> kdelibs- git-20120706.tar.bz2). If it is very important to know > which git commit was tagged, that can be added to the source just > before it is tarred up, similar to how README.svn-nightly was added > to our svn snapshots. One thing that is very important to us for any version that has a tarball and doesn't pull directly from a repository is that it has a stable / unique checksum. So having a 4.10.50_snapshot release that changes every week is a no go to us. If you want to provide a symlink in the FTP server with that name, that doesn't affect us, as we will have to fetch the exact tarball and not that generic symlink. The use of dates on the version number is something we can work with. As you're talking about automated releases, it would make our live easier if you did the release at a specific weekday (assuming weekly releases), but if you can use the same date for all components that are released, we can work with that. As you can see on [1][2] we keep a checksum of the tarballs in a Manifest file so that users can be sure the file they got is the same we used - that help us with broken mirrors and preventing cases where files are tampered. For the latter case having a file with checksums for all your tarballs[3] on your FTP site would be a great help. [1] - http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob_plain;f=kde-base/kate/Manifest;hb=refs/heads/master [2] - http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-base/kate/Manifest?revision=1.309&view=markup [3] - ftp://ftp.kde.org/pub/kde/stable/4.8.4/src/ > For the purposes of scripting, if it's OK to assume GNU tar then > the extracted directory name can include the date since we can use > --strip-components. But that option is non-POSIX. Plus there could > easily be non-shell tarball handlers (e.g. Ruby or Python) where > you might want to know what the extracted directory name should be. > So unless there's a compelling reason otherwise I would recommend > leaving any version information out of the extracted directory name > (e.g. kdelibs-git-20120706.tar.bz2 would decompress to just > kdelibs) To us it would be easier if the directory name matches the package name (kdelibs-4.8.10-beta-20120726.tar.bz2 -> kdelibs-4.8.10-beta-20120726), but if you define it will always be the basename (kdelibs) it also works for us. Given all the discussion about versions in this thread and to make sure the rules work well for all the distributions affected, perhaps it's time someone presents a table of versions and how they compare. In the case of Gentoo, our simplified rules[4][5] are the following: 5.2.1 > 5.2.0 > 5.1 > 5.0.9 > 5.0.0 > 4.9.50 we allow the use of suffixes with the following meaning: _alpha Alpha release (earliest) _beta Beta release _prePre release _rc Release candidate (no suffix) Normal release _p Patch level which compare as: 5.2.1_p1 > 5.2.1 > 5.2.0_p20120320 > 5.2.0_p20120318 > 5.2.0 > 5.2.0_rc20 > 5.2.0_rc10 > 5.2.0_pre2 > 5.2.0_beta6 > 5.2.0_beta5 > 5.2.0_alpha15
Re: Release Script
> On Sunday, July 08, 2012 02:30:13 Michael Jansen wrote: > > Gentoo already supports betas, RCs, etc. in Portage though they have a > > different nomenclature (e.g. I think 4.7.0~beta1 would be 4.7.0_beta1 in > > Portage). But in order to support generic KDE snapshots that nomenclature > > shouldn't change too much across future releases. As long as it's mostly set > > one time it shouldn't be hard to generically rewrite KDE versions into what > > is used by Gentoo (or rather, rewrite the Gentoo version to the KDE version > > to find the tarball!). > > > > All the rest is administrivia in my opinion for a packager (they can rely on > > a good-enough GNU tar since they can enforce its presence). I would just > > make sure that the only versioning info in *released* snapshot tarballs and > > directories is the version itself (i.e. no dates, no revision tags or > > commit ids). > > What is the version of a snapshot? Give an example. For me it is the date. What do you expect it to be? Just snapshot? Keep the misuse of stable version numbers? For a beta or RC, just use that version tag with no date (e.g. kdelibs-4.9.0~rc1). There would be no symlink to this as it's a real "release", not a snapshot. For the extracted directory name I would include the version name as that seems to be the standard style (I do that with my own software releases at least). For a routine nightly snapshot, use the date as the version, with a symlink to that module on the FTP server. The symlink name should mention that it's a snapshot of some sort (e.g. kdelibs-git.tar.bz2 -> kdelibs- git-20120706.tar.bz2). If it is very important to know which git commit was tagged, that can be added to the source just before it is tarred up, similar to how README.svn-nightly was added to our svn snapshots. For the purposes of scripting, if it's OK to assume GNU tar then the extracted directory name can include the date since we can use --strip-components. But that option is non-POSIX. Plus there could easily be non-shell tarball handlers (e.g. Ruby or Python) where you might want to know what the extracted directory name should be. So unless there's a compelling reason otherwise I would recommend leaving any version information out of the extracted directory name (e.g. kdelibs-git-20120706.tar.bz2 would decompress to just kdelibs) 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 Script
> Gentoo already supports betas, RCs, etc. in Portage though they have a > different nomenclature (e.g. I think 4.7.0~beta1 would be 4.7.0_beta1 in > Portage). But in order to support generic KDE snapshots that nomenclature > shouldn't change too much across future releases. As long as it's mostly set > one time it shouldn't be hard to generically rewrite KDE versions into what > is used by Gentoo (or rather, rewrite the Gentoo version to the KDE version > to find the tarball!). > > All the rest is administrivia in my opinion for a packager (they can rely on > a good-enough GNU tar since they can enforce its presence). I would just > make sure that the only versioning info in *released* snapshot tarballs and > directories is the version itself (i.e. no dates, no revision tags or > commit ids). Sorry either because i am a non native speaker or because i am missing something i can't follow you here. Please give a specific example of good and bad. What is the version of a snapshot? Give an example. For me it is the date. What do you expect it to be? Just snapshot? Keep the misuse of stable version numbers? Let me give some examples. UNSTABLE RELEASES kdelibs-4.8.5~snapshot.tgz (symlink to the tgz or real name) kdelibs-4.8.5~20121005.tgz (or whoever you think they should be named) kdelibs-4.8.5~alpha1.tgz kdelibs-4.8.5~beta1.tgz kdelibs-4.8.5~rc1.tgz What should the directory in the package be in that case? Examples for the alpha. kdelibs-4.5.8 kdelibs-4.5.8~alpha1/ (or ???) Anything else. STABLE RELEASE (It is clear here then. No change to current procedures) kdelibs-4.8.5.tgz -> kdelibs-4.8.5 > A final note: It sounds like we're going towards only releasing changed > packages between updates. I think this is a wonderful idea (as I hate > rebuilding a hojillion KDE packages on Gentoo just for a minor point > release) but it will be very labor-intensive for packagers if we don't > essentially do the work for them by listing out what libraries and > applications *individual* versions are present in a given KDE SC, for each > release. So there would need to be some kind of automated version > extraction (perhaps individual module maintainers could provide this until > that's available?) We will only start doing that when we are able to do it. That means when all the discussion led to a result. And i laid out my plan how to do it in a other mail. For me the only step that is still a bit dark is the versioning numbers. Because doing it with a script gives many problems you do not have when doing it manually. Especially when skipping unchanged modules. I already started a class trying to implement it and hope to present it in the next days. I am trying to make sure the code can handle all cases. Which means doing many unit test for it. The rest is just implementing. Mike___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Saturday, July 07, 2012 22:22:38 Michael Jansen wrote: > On Saturday, July 07, 2012 04:04:42 PM Michael Pyne wrote: > > On Saturday, July 07, 2012 18:27:42 Jorge Manuel B. S. Vicetto wrote: > > > >>> I think we did it for a time. At least i remember some " a new > > > >>> snow storm, a new snapshot" commits by dirk. But no idea how > > > >>> they got released/packaged. > > > >> > > > >> Yes, you did that in the past and we really disliked it. > > > > > > > > Could you find out how they were named back then for me? Just for > > > > information. > > > > > > > > Mike > > > > > > I can't recall the names used back then, but I'm pretty sure they > > > included the svn id in the names and dir inside the tarball. > > > I tried asking in #gentoo-kde but no one got back to me so I can't > > > help with that. > > > > You can look at ftp://ftp.kde.org/pub/kde/snapshots/ for an example of what > > they used to look like (packagename-svn-$revno.tar.bz2). > > > > This was made easier by later having symlinks available (packagename- > > svn.tar.bz2) (added by myself :P, see svn revision 458465 of kde- > > common/release/dosnapshot) but I can confirm it was a pain in the ass from a > > scripting perspective. > > > > Of course for packagers they wouldn't be using Subversion snapshots but > > plain tarball snapshots, although those suffer the same issues. In fact it > > was worse because the directory name that was extracted to was > > unpredictable (e.g. kdeadmin.tar.bz2 extracts to kdeadmin-1233410/). > > (Sorry for the other empty mail. Wrong button) > > So there is the problem i couldn't see. The directory name it extracts to is considered to be the same as the name of the archive. Just extracted our kdelibs 4.8.3 package and the dir is kdelibs-4.8.3. Build-tool already solves that problem by always using "tar --strip-components=1 --directory=". That's why i failed to see the problem. > > Is that naming a must? I think the issue is less about having the version component in the name and more that if there is a version component, that it is easy to piece toward the tagged version. Gentoo already supports betas, RCs, etc. in Portage though they have a different nomenclature (e.g. I think 4.7.0~beta1 would be 4.7.0_beta1 in Portage). But in order to support generic KDE snapshots that nomenclature shouldn't change too much across future releases. As long as it's mostly set one time it shouldn't be hard to generically rewrite KDE versions into what is used by Gentoo (or rather, rewrite the Gentoo version to the KDE version to find the tarball!). All the rest is administrivia in my opinion for a packager (they can rely on a good-enough GNU tar since they can enforce its presence). I would just make sure that the only versioning info in *released* snapshot tarballs and directories is the version itself (i.e. no dates, no revision tags or commit ids). For actual Git snapshots Gentoo uses a separate scheme anyways that even uses git directly, so that shouldn't pose much drama. But I don't think that's what's being discussed here. :) A final note: It sounds like we're going towards only releasing changed packages between updates. I think this is a wonderful idea (as I hate rebuilding a hojillion KDE packages on Gentoo just for a minor point release) but it will be very labor-intensive for packagers if we don't essentially do the work for them by listing out what libraries and applications *individual* versions are present in a given KDE SC, for each release. So there would need to be some kind of automated version extraction (perhaps individual module maintainers could provide this until that's available?) 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 Script
On Saturday, July 07, 2012 04:04:42 PM Michael Pyne wrote: > On Saturday, July 07, 2012 18:27:42 Jorge Manuel B. S. Vicetto wrote: > > >>> I think we did it for a time. At least i remember some " a new > > >>> snow storm, a new snapshot" commits by dirk. But no idea how > > >>> they got released/packaged. > > >> > > >> Yes, you did that in the past and we really disliked it. > > > > > > Could you find out how they were named back then for me? Just for > > > information. > > > > > > Mike > > > > I can't recall the names used back then, but I'm pretty sure they > > included the svn id in the names and dir inside the tarball. > > I tried asking in #gentoo-kde but no one got back to me so I can't > > help with that. > > You can look at ftp://ftp.kde.org/pub/kde/snapshots/ for an example of what > they used to look like (packagename-svn-$revno.tar.bz2). > > This was made easier by later having symlinks available (packagename- > svn.tar.bz2) (added by myself :P, see svn revision 458465 of kde- > common/release/dosnapshot) but I can confirm it was a pain in the ass from a > scripting perspective. > > Of course for packagers they wouldn't be using Subversion snapshots but > plain tarball snapshots, although those suffer the same issues. In fact it > was worse because the directory name that was extracted to was > unpredictable (e.g. kdeadmin.tar.bz2 extracts to kdeadmin-1233410/). (Sorry for the other empty mail. Wrong button) So there is the problem i couldn't see. The directory name it extracts to is considered to be the same as the name of the archive. Just extracted our kdelibs 4.8.3 package and the dir is kdelibs-4.8.3. Build-tool already solves that problem by always using "tar --strip-components=1 --directory=". That's why i failed to see the problem. Is that naming a must? I thought about naming the directory in the snapshot packages always like -/ kdelibs-5.8.5-SNAPSHOT/ or do people want just / kdelibs/ in there? -- Michael Jansen http://michael-jansen.biz___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Saturday, July 07, 2012 04:04:42 PM Michael Pyne wrote: > On Saturday, July 07, 2012 18:27:42 Jorge Manuel B. S. Vicetto wrote: > > >>> I think we did it for a time. At least i remember some " a new > > >>> snow storm, a new snapshot" commits by dirk. But no idea how > > >>> they got released/packaged. > > >> > > >> Yes, you did that in the past and we really disliked it. > > > > > > Could you find out how they were named back then for me? Just for > > > information. > > > > > > Mike > > > > I can't recall the names used back then, but I'm pretty sure they > > included the svn id in the names and dir inside the tarball. > > I tried asking in #gentoo-kde but no one got back to me so I can't > > help with that. > > You can look at ftp://ftp.kde.org/pub/kde/snapshots/ for an example of what > they used to look like (packagename-svn-$revno.tar.bz2). > > This was made easier by later having symlinks available (packagename- > svn.tar.bz2) (added by myself :P, see svn revision 458465 of kde- > common/release/dosnapshot) but I can confirm it was a pain in the ass from a > scripting perspective. > > Of course for packagers they wouldn't be using Subversion snapshots but > plain tarball snapshots, although those suffer the same issues. In fact it > was worse because the directory name that was extracted to was > unpredictable (e.g. kdeadmin.tar.bz2 extracts to kdeadmin-1233410/). > > Regards, > - Michael Pyne -- Michael Jansen http://michael-jansen.biz___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Saturday, July 07, 2012 18:27:42 Jorge Manuel B. S. Vicetto wrote: > >>> I think we did it for a time. At least i remember some " a new > >>> snow storm, a new snapshot" commits by dirk. But no idea how > >>> they got released/packaged. > >> > >> Yes, you did that in the past and we really disliked it. > > > > Could you find out how they were named back then for me? Just for > > information. > > > > Mike > > I can't recall the names used back then, but I'm pretty sure they > included the svn id in the names and dir inside the tarball. > I tried asking in #gentoo-kde but no one got back to me so I can't > help with that. You can look at ftp://ftp.kde.org/pub/kde/snapshots/ for an example of what they used to look like (packagename-svn-$revno.tar.bz2). This was made easier by later having symlinks available (packagename- svn.tar.bz2) (added by myself :P, see svn revision 458465 of kde- common/release/dosnapshot) but I can confirm it was a pain in the ass from a scripting perspective. Of course for packagers they wouldn't be using Subversion snapshots but plain tarball snapshots, although those suffer the same issues. In fact it was worse because the directory name that was extracted to was unpredictable (e.g. kdeadmin.tar.bz2 extracts to kdeadmin-1233410/). 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 Script
> > So you guys have some artificial version 4.x.49. which > > downloads sources from a branch and builds them? Artificial in not > > released by kde? > > What you call an "artificial version" is a mean for us to provide the > users who want to do it a package they can install and update whenever > they want to track a specific branch or the head of your git > repositories. But you're right, users will be using something that > wasn't released by KDE. As Andreas already mentioned, these packages > are only available on our KDE overlay and require extra work from > users before they can use them. Sorry that was not meant judging in any way. I wanted to make sure i understand if your recipes? only build hardcoded versions tested by you packagers and then put into the recipe regulary or if using them means living on the edge. I am just trying to have a complete understanding how you release our software. > We can do almost anything that can be done with bash to track your > packages, but it will be much simpler and quicker to add support for > packages that have reasonable and *predictable* names / versions. > I expect that you release kate snapshot tarballs with the same name > than the releases / pre-releases (kate). I am a bit unsure about that sentence. Could you elaborate? When scripted the tarball names will be stable. - I despise releasing a snapshot or alpha/beta release as something like 4.8.80 (alpha) or 5.80.50 (snapshot perhaps) So i am trying to end this misuse of a normal / stable version number (x.y.z) for unstable releases (snapshot, alpha, beta). A version could be 4.8.1(Stable: 1st update to 4.8.0) 4.8.1.1 (Stable: Repackaged 4.8.1 - under discusssion) 4.9.0~20120704- (Unstable SNAPSHOT release from the master branch while developing for 4.9.0) 4.9.0~SNAPSHOT (shortcut to the latest SNAPSHOT for your convenience.) 4.9.0~alpha1 (UNSTABLE alpha1 release) 4.9.0~alpha2 (UNSTABLE alpha2 release) 4.9.0~betal (UNSTABLE beta1 release) 4.9.0~beta2 (UNSTABLE beta2 release) 4.9.0(STABLE 4.9.0 release) But that is not necessary. If this discussion shows it is to much hassle for you (or anyone else that speaks up) i won't do it. > > So something like this (taking scotts email into account) > > > > kdebase-4.8.5-20120624- > > kdebase-4.8.5-20120701- > > kdebase-4.8.5-SNAPSHOT -> kdebase-4.8.5-20120701- > VERSION> > > > > would solve your problem? You noticed me putting a symbolic link kdebase-4.8.5-SNAPSHOT there that i plan to update on each and every new snapshot release? So you can just download the snapshot over the symbolic link and be sure you got the newest version. Perhaps that wasn't clear? My fault. If you still have a problem with that i must say i don't understand it. The filename does not get more predictable than that. That semver link i gave really shows how i think versioning should be done. Btw. That symlink means you couldn't provide your users with the possibility to build an older snapshot but i guess that use case is mood anyway? > No. As I've explained in the previous email and above, using git or > version tags force us to manually update packages and to go check each > and every package to determine what commit id was used on the package > name. As I've argued on the previous email, add that to a file inside > the tarball or make that available through the package UI, but don't > add that to the tarball name. > > > Can i interpret that that you guys would get problems too if we > > would not release all our packages with 4.9.2 . Remember we are > > talking about leaving unchanged packages out of the release on > > minor releases! > > This will cause issues for us now. But we're willing and ready to > update our tools if that's what will lay ahead. What we would like to > ask is that you please think it over so that we don't have the trouble > of updating our tools and in 1 month you rethink and reverse such a > change. > As Andreas already presented on his email, before you start doing > this, we really need you to document all your dependencies for each > package. > The best (easiest?) way to do that would be through the cmake files or > if you're willing to do that, to have a text file inside the tarballs > with that info. I am currently thinking about maintaining a special git repo that contains some release meta data. It will be branched in sync with kde sc releases so we will have KDE/4.8 and KDE/4.9 and master branches in there. It should contain one xml file that contains the latest released version for each package. If a package is added to KDE SC it will be added there and removed if it leaves KDE SC. This xml file will be the main configuration for the overall release process too. It will containt the repos where the package is found (git or svn), the branch name from which the package is released and perhaps something else. So if you want to know what makes up KDE 4.
Re: Release Script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04-07-2012 17:44, Michael Jansen wrote: > >>> >>> If you have a problem with us setting up weekly snapshots in >>> that format, then you may have a point because i am thinking >>> about that use case. Afaik some distros provide weekly >>> snapshots straight from our branches. If our release system is >>> fully scripted we could make weekly snapshot releases and ask >>> them to use those. They might look like that. Or perhaps have >>> the git or subversion number somewhere in the name. >> >> Then please *really* forget it. > > I have no idea why to tell me something like that: "Stop doing > thinking about stuff, stop trying to improve stuff, just go away. > That is what comes around here", instead of telling me just how you > guys work currently and together we figure out how everyone can be > happy? I'm not telling you to stop improving stuff, I'm asking you to forget a naming scheme that as I tried to show you will cause a lot of work for us (Gentoo and I assume other source distributions) with IMHO little gain. I even presented alternatives to make sure the tarballs convey a precise release without adding "unpredictable" strings to their version. > Glass half full please. > > If i would answer you in the same way i would just say: > > You guys currently get no snapshot releases from us so please > explain to me why us releasing some you can't use makes things > worse for you? Just ignore those snapshot releases, those that can > use them will be happy. But thats not my intention. > > I want to make clean i really appreciate that you are taking part > in the discussion here. So don't take offense. I just wanted to > point out that your emails look MUCH better without your first > sentence. And much more constructive. My first sentence was meant to convey how much your proposal (naming scheme) affects us and worries me. The reminder of the email was meant to show that I'm not just "flipping out" or making noise just for making noise. >> In the case of Gentoo, we start our work of doing a new KDE >> release by bumping the ebuild (Gentoo package format) version - >> for example we bump kdelibs-4.8.3 to kdelibs-4.8.4 or kate- >> to kate-4.8.95. As the name of the tarball that we try to >> download is based on the package version, if you have a > > So you guys have some artificial version 4.x.49. which > downloads sources from a branch and builds them? Artificial in not > released by kde? What you call an "artificial version" is a mean for us to provide the users who want to do it a package they can install and update whenever they want to track a specific branch or the head of your git repositories. But you're right, users will be using something that wasn't released by KDE. As Andreas already mentioned, these packages are only available on our KDE overlay and require extra work from users before they can use them. > So everyone out there having this version does not really know > which version he has? Because it depends on when he built? The same way as any KDE developer that uses packages from the git repositories. > You guys currently have no support to build snapshot versions (and > i realize we currently don't bprovide any). And it would be hard to > do unless we release all snapshot versions under the same PACKAGE > NAME EVERY TIME. What version is in the package is irrelevant. > Right? As you mention, we can't provide support for something you don't provide. We did provide for a while support for snapshots when you briefly released them sometime ago. We can do almost anything that can be done with bash to track your packages, but it will be much simpler and quicker to add support for packages that have reasonable and *predictable* names / versions. I expect that you release kate snapshot tarballs with the same name than the releases / pre-releases (kate). I haven't seen any suggestion to do otherwise. In the past there were some changes of package / tarball names or moves of a package from a tarball to another. That creates extra work for us, but as long as it isn't done without thinking or worse you do it a few times in a row, we can live with it. The package / tarball version is the crux of this discussion. We can support several naming schemes, so we're open to talk about that. What we really need is *consistency* and *predictability*. Whenever you name a package / tarball with an unpredictable name, you force us to have to check each package and to manually update our naming scheme. If you use a consistent and predictable naming scheme, all we need to do is copy a file and use the new package name (without having to go and check what tag was used for each of the packages that we're touching). > So something like this (taking scotts email into account) > > kdebase-4.8.5-20120624- > kdebase-4.8.5-20120701- > kdebase-4.8.5-SNAPSHOT -> kdebase-4.8.5-20120701- VERSION> > > would solve your problem? No. As I've explained in
Re: Release Script
The same naturally goes for stuff like kdeedu now that it split. What if some application got no commits since the last minor release. Make a release anyway or skip it? For major releases i guess making a package anyway makes sense. Or not? Releasing all parts of the SC with the same version numbers at the same time delivers a very clear implied message: "All of these parts are meant to work well together" and "This is the configuration we support". Different version numbers if all of the SC is still released together at the same time would still work here, although the "This belongs together" message is already a bit weaker. We will always release a KDE SC Framework Version. But the parts can have different versions. It is about decreasing the workload of everyone involved by not forcing releases of unchanged packages. At least thats what i am talking about. And a kdelibs hotfix (because of a security problem) does not require a full KDE SC Framework release with all packages. I will make sure we have always a up to date database about the parts that are supposed to work together. If you decide to split up the SC into separate smaller releases, you lose or weaken (depending on how you split) that implied message and you need to provide this information in another way, which means more work for the developers to document dependencies and more work for packagers to make sure that everything indeed is as it is supposed to be. That is nothing i work on or plan to do. My work will make that possible but i currently work on the assumption we will keep our current release practices. I am just trying to script it and make necessary changes to make life easier for all involved. Anything else is beyond my scope. Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Wednesday 27 June 2012 17:21:28 Michael Jansen wrote: > On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > > If we really want to decouple our releases and be more flexible with > > > > doing > > > > them i consider this change a requirement for any decision in that > > > > regard. > > > > > > > > > > > > > > > > Each and every module has to have its own version number build in. I > > > > guess > > > > with the frameworks branch much of kdelibs already got that change (no > > > > idea > > > > really, anyone with input?). But we have to do the same with the rest > > > > of > > > > our modules. > > > > > > No idea about frameworks. David? Kevin? > > > > This is partly still under discussion. > > > > However the currently implemented solution is that each framework has a > > versions number, but that version number can be upgraded in all frameworks > > at the same time, using a script. > > > > A future framework on top of all others, could provide the version number > > for all apps, much like the current kdeversion.h. Basically it would be > > the > > "SC" number, and not the version number of the libs themselves, as is > > currently the case. > > But that SC number would be a lie. Because you only assume all modules are > installed in the versions that were release as SC X.Y . You have no idea if > the user or distro uses older or newer versions for some libraries, modules > or apps. So that number has no information value. Perhaps some marketing > value. But in bug reports it is useless. > > Do we release kdelibs as ONE package. Or do we plan to release many small > packages? > > If each library gets released standalone. What if whe make the kde sc > release 4.10.7. I assume only 70% of all libraries got commits since 4.10.6 > because stuff is pretty stable by now (7th update). Do we still release ALL > libs or only those that got changed? Does this make a difference for our > packagers? Does it make it more difficult or more easy? So is that a > feature we want or not? > > The same naturally goes for stuff like kdeedu now that it split. What if > some application got no commits since the last minor release. Make a > release anyway or skip it? For major releases i guess making a package > anyway makes sense. Or not? Releasing all parts of the SC with the same version numbers at the same time delivers a very clear implied message: "All of these parts are meant to work well together" and "This is the configuration we support". Different version numbers if all of the SC is still released together at the same time would still work here, although the "This belongs together" message is already a bit weaker. If you decide to split up the SC into separate smaller releases, you lose or weaken (depending on how you split) that implied message and you need to provide this information in another way, which means more work for the developers to document dependencies and more work for packagers to make sure that everything indeed is as it is supposed to be. There is also a difference if you split into frameworks, workspace and apps, or if you release every single tarball on its own schedule. The first is still well managable for both developers and packagers with regards to dependency documentation. The latter will just result in a big mess. Gnome and X are prime examples that this does not work. Grs, Heinz 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 Script
On Tuesday 03 July 2012 19:25:13 Michael Jansen wrote: > > I do not disagree here, BUT have in mind that since we have private > > packages (used/tested by distro packagers before the release actually > > happens) so YOU is a broad term including the packagers. > > > > > For KDE would say someone else should decide. We could make a release > > > 4.8.80.1 if we have to repackage stuff. But the packagers distros should > > > give input here. I think they should say what is the easiest for them to > > > handle. > > > > I'm sure having a micro release is going to break their scripts that just > > expect 3 numbers. > > I really would like to have some input of real packagers here. I am inclined > to say if noone speaks up now they have to live with whatever we come up > afterwards. I am not caring for people who only complain after stuff is > done when they kept silent while it was discussed and designed. > > INPUT guys. NOW. The format of the version numbering scheme does not affect slackware packaging. A slightly bigger impact would be to have different version numbers of the individual components. Grs, Heinz 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 Script
On Friday, July 06, 2012 12:21:56 AM Albert Astals Cid wrote: > I think i was quite clear this list is were we decide how releases are done > on my e-mails to the kde-packager mailing list. Definitely. That's exactly why I subscribed. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
El Dijous, 5 de juliol de 2012, a les 21:26:40, Andreas K. Huettel va escriure: > Am Dienstag 03 Juli 2012, 19:25:13 schrieb Michael Jansen: > > I really would like to have some input of real packagers here. I am > > inclined to say if noone speaks up now they have to live with whatever we > > come up afterwards. I am not caring for people who only complain after > > stuff is done when they kept silent while it was discussed and designed. > > > > INPUT guys. NOW. > > It probably helps if you cc the packager mailing list. I think i was quite clear this list is were we decide how releases are done on my e-mails to the kde-packager mailing list. Cheers, Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
> > In the case of Gentoo, we start our work of doing a new KDE release by > > bumping the ebuild (Gentoo package format) version - for example we > > bump kdelibs-4.8.3 to kdelibs-4.8.4 or kate- to kate-4.8.95. > > As the name of the tarball that we try to download is based on the > > package version, if you have a > > So you guys have some artificial version 4.x.49. which downloads > sources from a branch and builds them? Artificial in not released by kde? > > So everyone out there having this version does not really know which > version he has? Because it depends on when he built? These versions are hardmasked and usually not visible to users. The build log contains timestamp and git commit hash of every repository involved, and is a hard requirement so we even look at a bug report. BTW, this actually makes Gentoo a great distribution for KDE development, you can very easily run newest master and it's fully integrated with the distribution package management. > > Can i interpret that that you guys would get problems too if we would not > release all our packages with 4.9.2 . Remember we are talking about leaving > unchanged packages out of the release on minor releases! > See separate mail, yes right now we're relying on same version number for all of KDE. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ 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 Script
Am Dienstag 03 Juli 2012, 19:25:13 schrieb Michael Jansen: > > I really would like to have some input of real packagers here. I am > inclined to say if noone speaks up now they have to live with whatever we > come up afterwards. I am not caring for people who only complain after > stuff is done when they kept silent while it was discussed and designed. > > INPUT guys. NOW. > It probably helps if you cc the packager mailing list. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ 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 Script
Am Samstag 30 Juni 2012, 15:29:37 schrieb Albert Astals Cid: > > > For KDE would say someone else should decide. We could make a release > > 4.8.80.1 if we have to repackage stuff. But the packagers distros should > > give input here. I think they should say what is the easiest for them to > > handle. > > I'm sure having a micro release is going to break their scripts that just > expect 3 numbers. Breaking the scripts once, with a well-thought-out change, is perfectly fine... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ 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 Script
Am Mittwoch 27 Juni 2012, 17:39:03 schrieb Michael Jansen: > On Monday, June 25, 2012 01:16:05 AM Albert Astals Cid wrote: > > That works fine for me, though unfortunately we usually have to > > re-package some tarballs due to fixes that are needed into the release. > > How do you fit this particularity into this way of working? > > With my config manager head on i say "NEVER rerelease a version". Which in > our case includes everything that has been downloaded/used by anone not > you (You=Packager). Very strong agreement. If you want to re-release something, add an extra .x to the version number. > > > I see one problem. As you can see the changed version information is > > > only committed AFTER build and test in this setup. That can take quite > > > some time. In a project as big as ours that opens the possibility that > > > during that time some else commits a change. Which makes it impossible > > > for the script to commits its change. > > > > > > 1. Solution: Branch. The Script could create a branch for the release. > > > > Creating a branch for release would also probably "fix" the problem i > > spoke in the previous paragraph * Create a branch. * Build and test that branch. * Tag the release on that branch. * Merge the branch back into master / whatever it comes from. > > I am btw. wondering that noone objected yet to this. I seem to remember > someone was unhappy about dirk branching some 4.8.x release. I don't > remember where and why. Dunno. It was just funny, because, functionality-wise, master became 4.8 and 4.8 became 4.8.X. > > > > 2. Solution: Lock the repo (A no go in my opinion) > > > > Yeah, locking kills babies Ack. Not that it affects me, but the KDE developers will probably object to locking, with good reason. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ 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 Script
Am Dienstag 03 Juli 2012, 19:30:23 schrieb Michael Jansen: > I am just wondering about the distros again. Say i release KDE SC 4.9.2 and > of all our packages only 10% got really changes. I wonder how that affects > the workload if we force a release of the 90% unchanged ones. Or do they > need them to be released? Gentoo case: Assuming nothing else is broken, the workload for the packagers of bumping every package from 4.9.1 to 4.9.2 is near zero. (Running a script over a git tree.) The main disadvantage is that all users will have to re- download all sources. But then, we're as a source based distro maybe a special case. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ 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 Script
Am Mittwoch 27 Juni 2012, 17:21:28 schrieb Michael Jansen: > > This is partly still under discussion. > > > > However the currently implemented solution is that each framework has a > > versions number, but that version number can be upgraded in all > > frameworks at the same time, using a script. > > > > A future framework on top of all others, could provide the version number > > for all apps, much like the current kdeversion.h. Basically it would be > > the "SC" number, and not the version number of the libs themselves, as > > is currently the case. > > But that SC number would be a lie. Because you only assume all modules are > installed in the versions that were release as SC X.Y . You have no idea if > the user or distro uses older or newer versions for some libraries, modules > or apps. So that number has no information value. Perhaps some marketing > value. But in bug reports it is useless. Right now, in Gentoo we're basically relying on the fact that all kde sc packages that are installed have the same exact version (modulo local Gentoo revbumps with patches). However, this is not a "must". If you want, you can give each and every small component of (what used to be) KDE a separate version number. But... *before* you do this, you'll need to define exactly what dependencies you will require across the *entire* software set, taking into account version numbers! Right now, if someone installs (on Gentoo) gwenview-4.8.4, this pulls in as a dependency libkonq-4.8.4. Now, this is likely overspecified, and we might be fine with libkonq-4.8.*. So, a general rule for the moment may be gwenview- X.Y.Z requires libkonq-X.Y.*. Now, please give me the specifications for the new version numbering first, before you start using them! In particular also... what are major, minor, bugfix releases, what do you want to enforce in a dependency freeze, ... Cheers... -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ 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 Script
Am Mittwoch 20 Juni 2012, 21:30:23 schrieb Michael Jansen: > > 1. Add the version information into all of our modules in a way that a > outside script can get it. Some kind of file for example that is included > by the toplevel CMakeLists.txt and only contains the version information. Sounds good. > 2. Make the necessary build-system changes to use this version information > for the .SO names. Makes no sense, because soversions are already different. Better completely decouple from package version. > 3. Make it a rule that there is no other place allowed to contain version > information. If you need it somewhere else use cmakes configure_file(). > Btw. the version information should contain a human readable part > 4.8.3-beta2 too. (For the kdepims out there). Sounds good. > 5. Add a file into our modules that describe what to pack/ignore for our > source distributions. This contains the "removestuff" script parts from > kde- common/release. Use a file-format that is extensible (JSON, xml, > ...). And add possibly more (time will tell) Sounds very good. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ 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 Script
> > > > If you have a problem with us setting up weekly snapshots in that > > format, then you may have a point because i am thinking about that > > use case. Afaik some distros provide weekly snapshots straight from > > our branches. If our release system is fully scripted we could make > > weekly snapshot releases and ask them to use those. They might look > > like that. Or perhaps have the git or subversion number somewhere > > in the name. > > Then please *really* forget it. I have no idea why to tell me something like that: "Stop doing thinking about stuff, stop trying to improve stuff, just go away. That is what comes around here", instead of telling me just how you guys work currently and together we figure out how everyone can be happy? Glass half full please. If i would answer you in the same way i would just say: You guys currently get no snapshot releases from us so please explain to me why us releasing some you can't use makes things worse for you? Just ignore those snapshot releases, those that can use them will be happy. But thats not my intention. I want to make clean i really appreciate that you are taking part in the discussion here. So don't take offense. I just wanted to point out that your emails look MUCH better without your first sentence. And much more constructive. > In the case of Gentoo, we start our work of doing a new KDE release by > bumping the ebuild (Gentoo package format) version - for example we > bump kdelibs-4.8.3 to kdelibs-4.8.4 or kate- to kate-4.8.95. > As the name of the tarball that we try to download is based on the > package version, if you have a So you guys have some artificial version 4.x.49. which downloads sources from a branch and builds them? Artificial in not released by kde? So everyone out there having this version does not really know which version he has? Because it depends on when he built? You guys currently have no support to build snapshot versions (and i realize we currently don't bprovide any). And it would be hard to do unless we release all snapshot versions under the same PACKAGE NAME EVERY TIME. What version is in the package is irrelevant. Right? So something like this (taking scotts email into account) kdebase-4.8.5-20120624- kdebase-4.8.5-20120701- kdebase-4.8.5-SNAPSHOT -> kdebase-4.8.5-20120701- would solve your problem? Can i interpret that that you guys would get problems too if we would not release all our packages with 4.9.2 . Remember we are talking about leaving unchanged packages out of the release on minor releases! 4.9.0 gets releases of kalgebra-4.9.0.tar.xz ktuberling-4.9.0.tar.xz okular-4.9.0.tar.xz 4.9.1 gets releases of okular-4.9.1.tar.xz ktuberling unchanged kalgebra unchanged 4.9.2 gets releases of kalgebra-4.9.1.tar.xz ktuberling-4.9.1.tar.xz okular-4.9.2.tar.xz The kubuntu guys seem to prefer this? or is it 4.9.2 for all packages in the 4.9.2 SC Release? Scott?) > > I think we did it for a time. At least i remember some " a new snow > > storm, a new snapshot" commits by dirk. But no idea how they got > > released/packaged. > > Yes, you did that in the past and we really disliked it. Could you find out how they were named back then for me? Just for information. Mike___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Tuesday, July 03, 2012 07:14:40 PM Michael Jansen wrote: > > > The last step is done in maven because the support something called > > > snapshot release which means their version looks like > > > 4.7.1-20120621_151400. I think it could make sense to support that > > > too. Stuff build from master or branch would be easily > > > distuinguishable from really released stuff. > > > > If you're suggesting to use -.tar.xz tarballs, > > then please forget that. That may not affect binary distributions, but > > it affects source distributions. > > Source distributions really appreciate consistent and *predictable* > > names and URLs. > > I can not see where you got the impression that i would like to do that for > major, minor or patch release. Standard KDE releases will always have real > version numbers like today, > > If you have a problem with us setting up weekly snapshots in that format, > then you may have a point because i am thinking about that use case. Afaik > some distros provide weekly snapshots straight from our branches. If our > release system is fully scripted we could make weekly snapshot releases and > ask them to use those. They might look like that. Or perhaps have the git > or subversion number somewhere in the name. > > IF we really do that. > > I think we did it for a time. At least i remember some " a new snow storm, a > new snapshot" commits by dirk. But no idea how they got released/packaged. For Kubuntu (and any system based on Debian packaging), we need the version numbers to be monotonically increasing. Subversion revision number have this property, but Git tags to do not. Date tags (e.g. -MM-DD) work very nicely and since you're not planning on more than once per day releases, they take care of the sorting issue. It also removes the need to deal with svn and git hosted packages differently. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Tuesday, July 03, 2012 07:25:13 PM Michael Jansen wrote: > > I do not disagree here, BUT have in mind that since we have private > > packages (used/tested by distro packagers before the release actually > > happens) so YOU is a broad term including the packagers. > > > > > > > > > For KDE would say someone else should decide. We could make a release > > > 4.8.80.1 if we have to repackage stuff. But the packagers distros should > > > give input here. I think they should say what is the easiest for them to > > > handle. > > > > > > > > I'm sure having a micro release is going to break their scripts that just > > expect 3 numbers. > > I really would like to have some input of real packagers here. I am > inclined to say if noone speaks up now they have to live with whatever we > come up afterwards. I am not caring for people who only complain after > stuff is done when they kept silent while it was discussed and designed. > > INPUT guys. NOW. For Kubuntu the key thing is that version numbers monotonically increase and that the version number changes each time the contents change. If we have a script that gets confused by a fourth digit I think it's buggy and we should fix it. Currently, when packages are in the private testing phase we internally increment the versions with additional letters when a tarball gets respun (i.e. change 4.8.80 to 4.8.80a when the private tarball is changed). I'm not sure the full context of the discussion, but if what's on the table might include a fourth digit for these private respins, that would make things easier for Kubuntu. Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Tuesday, July 03, 2012 07:30:23 PM Michael Jansen wrote: ... > I am just wondering about the distros again. Say i release KDE SC 4.9.2 and > of all our packages only 10% got really changes. I wonder how that affects > the workload if we force a release of the 90% unchanged ones. Or do they > need them to be released? ... For Kubuntu we look through and only release the packages that have changes, so not releasing unchanged packages in point releases would make our life easier (in case there's doubt, I'm not sure from the above, KDE does release the unchanged ones now). Scott K ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
> Speaking in the apps side (not frameworks) > > I think it makes sense to release anyway since we are using the version > numbers of SC for the tarballs (which might not be a good idea), but i would > feel confused if this happens > > 4.9.0 gets releases of > kalgebra-4.9.0.tar.xz > ktuberling-4.9.0.tar.xz > okular-4.9.0.tar.xz > > 4.9.1 gets releases of > okular-4.9.1.tar.xz > > 4.9.2 gets releases of > kalgebra-4.9.2.tar.xz > ktuberling-4.9.2.tar.xz > okular-4.9.1.tar.xz > > As a user i'd think, what happened to kalgebra-4.9.1.tar.xz and > ktuberling-4.9.1.tar.xz ? One solution would be to release 4.9.1 of ktuberling and kalgebra with KDE SC 4.9.2 . Since the first number is the app version and the second number is the KDE SC Version. Which only look related in this example but on a config management scale are unrelated. I am just wondering about the distros again. Say i release KDE SC 4.9.2 and of all our packages only 10% got really changes. I wonder how that affects the workload if we force a release of the 90% unchanged ones. Or do they need them to be released? Yes this is a unlikely number but remember with kde frameworks we split up kdelibs in a thousand packages. Let them mature a bit and we will get there. For now i will ignore that. The script should be able to handle both cases and configurably so. I think we have talked about everything i wanted to talk about. I will start with the release building script. Mike___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
> I do not disagree here, BUT have in mind that since we have private packages > (used/tested by distro packagers before the release actually happens) so > YOU is a broad term including the packagers. > > > For KDE would say someone else should decide. We could make a release > > 4.8.80.1 if we have to repackage stuff. But the packagers distros should > > give input here. I think they should say what is the easiest for them to > > handle. > > I'm sure having a micro release is going to break their scripts that just > expect 3 numbers. I really would like to have some input of real packagers here. I am inclined to say if noone speaks up now they have to live with whatever we come up afterwards. I am not caring for people who only complain after stuff is done when they kept silent while it was discussed and designed. INPUT guys. NOW. > > I am btw. wondering that noone objected yet to this. I seem to remember > > someone was unhappy about dirk branching some 4.8.x release. I don't > > remember where and why. > > No, Dirk didn't branch any release, he created a 4.8.x branch, which doesn't > make sense since KDE/4.8 branch is exactly that. OK. > > What i'm saying is create a 4.8.80 branch where we can cherry-pick the > needed fixes for re-packaging 4.8.80 because right now this can happen > > Imagine the 4.10 Beta 1 release in a few months, current behaviour would be > * Package 4.9.80 from master branch > * People keep adding fixes and whatnot to master > * You realize there's some compile problem in platform X > * You need to repackage 4.9.80 to include the fix, but since you have no > 4.9.80 branch you have two options: >- Update wholesale to the mater branch including not only the fix but all > the other commits too >- Manually include the fix in the tarball, making git tagging impossible > since there's no hash commit anymore with the contents you are releasing > > If we create a 4.9.80 branch this issue is fixed, since you cherry-pick > there and re-create the tarball. Exactly what i had in mind. The only thing left to decide is the name of the recreated tarball. > > > > 2. Solution: Lock the repo (A no go in my opinion) > > > > > > Yeah, locking kills babies > > > > > > > And a little problem. The feasability of beeing able to build our > > > > software > > > > before packaging. I already have a solution to build the packages with > > > > build- tool as a test. But no idea yet how to combine build-tool with > > > > this > > > > script unless i add this into build-tool. And the admins would like to > > > > have > > > > python. Not ruby. And build-tool would not mash with the idea to use > > > > jenkins to trigger the releases. > > > > > > "this script" == maven? > > > > I will not use maven. I just steal some workflow there. This script is the > > script which we currently try to hammer out how it should work. > > Not sure I see the problem then, can't you just invoke build-tool from the > script that you/us are creating? I hope so. There will be some need for twisting and matching. Because build- tool has a different use case. But since i have quite some experience now with doing that kind of scripts i can probably come up with a poor mans build-tool in python that has the minimum features required. - Build everything in the right order - Build just one module - Keep logfiles in a central place - Maintain the environment so the actual build-machine does not matter. - Work over problems and record a overall state at the end. > > But that probably breaks > > > > ~/ws/src/KDE/kdelibs : git describe > > v4.8.90-26-g1dd5c9d > > > > Which i personally do not care about. I won't stop doing the right thing > > because it is inconvenient. > > I'm not a git knowledgeable person, what would exactly break and why? AFAIK that reports how far away you are from the last tag. I have no idea if this jumps over branches following merges or if the tag HAS TO BE in the straight history of your current version. The example given means i am on a version that is a successor of v4.8.90. I have exactly 26 commits on top of that. The 'g' is for git and the rest the commit id. Mike___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
> > The last step is done in maven because the support something called > > snapshot release which means their version looks like > > 4.7.1-20120621_151400. I think it could make sense to support that > > too. Stuff build from master or branch would be easily > > distuinguishable from really released stuff. > > If you're suggesting to use -.tar.xz tarballs, > then please forget that. That may not affect binary distributions, but > it affects source distributions. > Source distributions really appreciate consistent and *predictable* > names and URLs. > I can not see where you got the impression that i would like to do that for major, minor or patch release. Standard KDE releases will always have real version numbers like today, If you have a problem with us setting up weekly snapshots in that format, then you may have a point because i am thinking about that use case. Afaik some distros provide weekly snapshots straight from our branches. If our release system is fully scripted we could make weekly snapshot releases and ask them to use those. They might look like that. Or perhaps have the git or subversion number somewhere in the name. IF we really do that. I think we did it for a time. At least i remember some " a new snow storm, a new snapshot" commits by dirk. But no idea how they got released/packaged. Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
El Dimecres, 27 de juny de 2012, a les 17:39:03, vau escriure: > On Monday, June 25, 2012 01:16:05 AM Albert Astals Cid wrote: > > That works fine for me, though unfortunately we usually have to re-package > > some tarballs due to fixes that are needed into the release. How do you > > fit > > this particularity into this way of working? > > With my config manager head on i say "NEVER rerelease a version". Which in > our case includes everything that has been downloaded/used by anone not you > (You=Packager). I do not disagree here, BUT have in mind that since we have private packages (used/tested by distro packagers before the release actually happens) so YOU is a broad term including the packagers. > For KDE would say someone else should decide. We could make a release > 4.8.80.1 if we have to repackage stuff. But the packagers distros should > give input here. I think they should say what is the easiest for them to > handle. I'm sure having a micro release is going to break their scripts that just expect 3 numbers. > > > I see one problem. As you can see the changed version information is > > > only > > > committed AFTER build and test in this setup. That can take quite some > > > time. In a project as big as ours that opens the possibility that during > > > that time some else commits a change. Which makes it impossible for the > > > script to commits its change. > > > > > > 1. Solution: Branch. The Script could create a branch for the release. > > > > Creating a branch for release would also probably "fix" the problem i > > spoke > > in the previous paragraph > > You mean the repackaging? Yes. > I am btw. wondering that noone objected yet to this. I seem to remember > someone was unhappy about dirk branching some 4.8.x release. I don't > remember where and why. No, Dirk didn't branch any release, he created a 4.8.x branch, which doesn't make sense since KDE/4.8 branch is exactly that. What i'm saying is create a 4.8.80 branch where we can cherry-pick the needed fixes for re-packaging 4.8.80 because right now this can happen Imagine the 4.10 Beta 1 release in a few months, current behaviour would be * Package 4.9.80 from master branch * People keep adding fixes and whatnot to master * You realize there's some compile problem in platform X * You need to repackage 4.9.80 to include the fix, but since you have no 4.9.80 branch you have two options: - Update wholesale to the mater branch including not only the fix but all the other commits too - Manually include the fix in the tarball, making git tagging impossible since there's no hash commit anymore with the contents you are releasing If we create a 4.9.80 branch this issue is fixed, since you cherry-pick there and re-create the tarball. > > > 2. Solution: Lock the repo (A no go in my opinion) > > > > Yeah, locking kills babies > > > > > And a little problem. The feasability of beeing able to build our > > > software > > > before packaging. I already have a solution to build the packages with > > > build- tool as a test. But no idea yet how to combine build-tool with > > > this > > > script unless i add this into build-tool. And the admins would like to > > > have > > > python. Not ruby. And build-tool would not mash with the idea to use > > > jenkins to trigger the releases. > > > > "this script" == maven? > > I will not use maven. I just steal some workflow there. This script is the > script which we currently try to hammer out how it should work. Not sure I see the problem then, can't you just invoke build-tool from the script that you/us are creating? > > > > 4. Allow the script to maintain the version increase. We have to decide > > > how > > > to solve the race condition inherent in this. > > > > Don't understand what you mean by this. > > The race condition here is the part where i talked about the script checking > out some sources. Working for two hours (compiling, testing, packaging) and > then wanting to commit its changes. When someone else committed something > in that time it cannot do that on our KDE/4.x branch. The solution i prefer > would be to create a KDE/4.x.3 branch and commit there. That works for me. > But that probably breaks > > ~/ws/src/KDE/kdelibs : git describe > v4.8.90-26-g1dd5c9d > > Which i personally do not care about. I won't stop doing the right thing > because it is inconvenient. I'm not a git knowledgeable person, what would exactly break and why? > > > In general it seems a very well though out proposal, i don't see any > > obvious problem in what you are describing. > > > > One thing that is problematic with the current build scripts is the need > > of > > having up to date meinproc+kdoctools to build the packages that come after > > kdelibs, do you think that'd be an issue? > > Not really. Because this script will not care. It only releases for now. Sure, it only does releases, but our releases include running meinproc right now to create the index cache files
Re: Release Script
(Sorry sent too early) El Dissabte, 30 de juny de 2012, a les 15:12:06, Albert Astals Cid va escriure: > El Dimecres, 27 de juny de 2012, a les 17:21:28, Michael Jansen va escriure: > > On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > > > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > > > If we really want to decouple our releases and be more flexible with > > > > > doing > > > > > them i consider this change a requirement for any decision in that > > > > > regard. > > > > > > > > > > > > > > > > > > > > Each and every module has to have its own version number build in. I > > > > > guess > > > > > with the frameworks branch much of kdelibs already got that change > > > > > (no > > > > > idea > > > > > really, anyone with input?). But we have to do the same with the > > > > > rest > > > > > of > > > > > our modules. > > > > > > > > No idea about frameworks. David? Kevin? > > > > > > This is partly still under discussion. > > > > > > However the currently implemented solution is that each framework has a > > > versions number, but that version number can be upgraded in all > > > frameworks > > > at the same time, using a script. > > > > > > A future framework on top of all others, could provide the version > > > number > > > for all apps, much like the current kdeversion.h. Basically it would be > > > the > > > "SC" number, and not the version number of the libs themselves, as is > > > currently the case. > > > > But that SC number would be a lie. Because you only assume all modules are > > installed in the versions that were release as SC X.Y . You have no idea > > if > > the user or distro uses older or newer versions for some libraries, > > modules > > or apps. So that number has no information value. Perhaps some marketing > > value. But in bug reports it is useless. > > > > Do we release kdelibs as ONE package. Or do we plan to release many small > > packages? > > > > If each library gets released standalone. What if whe make the kde sc > > release 4.10.7. I assume only 70% of all libraries got commits since > > 4.10.6 > > because stuff is pretty stable by now (7th update). Do we still release > > ALL > > libs or only those that got changed? Does this make a difference for our > > packagers? Does it make it more difficult or more easy? So is that a > > feature we want or not? > > > > The same naturally goes for stuff like kdeedu now that it split. What if > > some application got no commits since the last minor release. Make a > > release anyway or skip it? For major releases i guess making a package > > anyway makes sense. Or not? Speaking in the apps side (not frameworks) I think it makes sense to release anyway since we are using the version numbers of SC for the tarballs (which might not be a good idea), but i would feel confused if this happens 4.9.0 gets releases of kalgebra-4.9.0.tar.xz ktuberling-4.9.0.tar.xz okular-4.9.0.tar.xz 4.9.1 gets releases of okular-4.9.1.tar.xz 4.9.2 gets releases of kalgebra-4.9.2.tar.xz ktuberling-4.9.2.tar.xz okular-4.9.1.tar.xz As a user i'd think, what happened to kalgebra-4.9.1.tar.xz and ktuberling-4.9.1.tar.xz ? On the other hand we might want to use the *real* version of the application and not of the SC, then it might make sense to skip if no changes happen. Cheers, Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
El Dimecres, 27 de juny de 2012, a les 17:21:28, Michael Jansen va escriure: > On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > > If we really want to decouple our releases and be more flexible with > > > > doing > > > > them i consider this change a requirement for any decision in that > > > > regard. > > > > > > > > > > > > > > > > Each and every module has to have its own version number build in. I > > > > guess > > > > with the frameworks branch much of kdelibs already got that change (no > > > > idea > > > > really, anyone with input?). But we have to do the same with the rest > > > > of > > > > our modules. > > > > > > No idea about frameworks. David? Kevin? > > > > This is partly still under discussion. > > > > However the currently implemented solution is that each framework has a > > versions number, but that version number can be upgraded in all frameworks > > at the same time, using a script. > > > > A future framework on top of all others, could provide the version number > > for all apps, much like the current kdeversion.h. Basically it would be > > the > > "SC" number, and not the version number of the libs themselves, as is > > currently the case. > > But that SC number would be a lie. Because you only assume all modules are > installed in the versions that were release as SC X.Y . You have no idea if > the user or distro uses older or newer versions for some libraries, modules > or apps. So that number has no information value. Perhaps some marketing > value. But in bug reports it is useless. > > Do we release kdelibs as ONE package. Or do we plan to release many small > packages? > > If each library gets released standalone. What if whe make the kde sc > release 4.10.7. I assume only 70% of all libraries got commits since 4.10.6 > because stuff is pretty stable by now (7th update). Do we still release ALL > libs or only those that got changed? Does this make a difference for our > packagers? Does it make it more difficult or more easy? So is that a > feature we want or not? > > The same naturally goes for stuff like kdeedu now that it split. What if > some application got no commits since the last minor release. Make a > release anyway or skip it? For major releases i guess making a package > anyway makes sense. Or not? I think it makes sense to release anyway since we are using the version numbers of SC for the tarballs (which might not be a good idea), but i would feel confused if this happens 4.9.0 gets releases of kalgebra-4.9.0.tar.xz ktuberling-4.9.0.tar.xz okular-4.9.0.tar.xz 4.9.1 gets releases of okular-4.9.1.tar.xz ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20-06-2012 19:30, Michael Jansen wrote: > Hi > > I started to work on some script to help with our release creation > and studied both dirks and allens scripts for input. But the recent > discussion and my personal experience in doing releases (working as > a software configuration manager) made me realize i (or better we) > should take a step back and think about that process first before > scripting it. > > This is the chance and perfect time to solve the release problem > once and for all. There are quite some people aware there is room > for improvements and there currently is a lot of discussion and > action going on. > The last step is done in maven because the support something called > snapshot release which means their version looks like > 4.7.1-20120621_151400. I think it could make sense to support that > too. Stuff build from master or branch would be easily > distuinguishable from really released stuff. If you're suggesting to use -.tar.xz tarballs, then please forget that. That may not affect binary distributions, but it affects source distributions. Source distributions really appreciate consistent and *predictable* names and URLs. > Mike > > ___ release-team > mailing list release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team > - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJP7vM1AAoJEC8ZTXQF1qEPmAEQAJFfCdJm9WjaflmoNVR3bhm4 0da4QPTL7PO6+/8aqRTW7PkycWRK9l+NSW3K46XmO3q/hVkiMktp+1CSfOc/bSqG ppBi8LmLpxNhXxCfqAQezwzHUouS+ZIi2/7l84MJurOy7BTJASb7UTtKtJHSSkS1 /rsQVM+QcMiB2aS34ZyaAgG7czJg3dKvQGf7299gJwITlAILSH/fTCNm3fUW4lQZ eKri+CnEXYESRKKXGcAsZD1qeLE5OepxHBwA5jpteYthvls9BJ0R3QVR0C+yB9zL UvedpPp/odnmbubgG/meaAIMY+AhTTj5x3L/jGqRuA67UEUG/ZfnXU77gbsz9e5m BRxfrIS/0m8jbHWv2LkmIXbfSpG7vBuMgtMOWMQ3kf/0tU+9NZaaSET96Ywt2SDQ Rdym3ZXb1v9WnQpjHVzJSZky8DK9i5O0ahzrekgjWmyREjY039FY19fQ0ReOYuil pE40MIv37DHDmKW7YjJw0CijqsoyFdT7KWrWTvZYLhntHSeZ2XGrRM93rGOFYqFC hrCEsVgVfG/2I2mhnBR6DTSFMmW7Ag2J4SS8wuQ/s90esk7QuYN5J/W1b+zLKCPz lRq83cgtjf5u7kkZ9j0yFp5Kq1PkuqS8Lkld+y/Ef5KqBCST+AtyG3DITNtbTeaz phaH34+4Mpq39x/hHbqj =yls0 -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Monday, June 25, 2012 01:05:49 PM David Faure wrote: > On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > > If we really want to decouple our releases and be more flexible with > > > doing > > > them i consider this change a requirement for any decision in that > > > regard. > > > > > > > > > > > > Each and every module has to have its own version number build in. I > > > guess > > > with the frameworks branch much of kdelibs already got that change (no > > > idea > > > really, anyone with input?). But we have to do the same with the rest of > > > our modules. > > > > No idea about frameworks. David? Kevin? > > This is partly still under discussion. > > However the currently implemented solution is that each framework has a > versions number, but that version number can be upgraded in all frameworks > at the same time, using a script. > > A future framework on top of all others, could provide the version number > for all apps, much like the current kdeversion.h. Basically it would be the > "SC" number, and not the version number of the libs themselves, as is > currently the case. But that SC number would be a lie. Because you only assume all modules are installed in the versions that were release as SC X.Y . You have no idea if the user or distro uses older or newer versions for some libraries, modules or apps. So that number has no information value. Perhaps some marketing value. But in bug reports it is useless. Do we release kdelibs as ONE package. Or do we plan to release many small packages? If each library gets released standalone. What if whe make the kde sc release 4.10.7. I assume only 70% of all libraries got commits since 4.10.6 because stuff is pretty stable by now (7th update). Do we still release ALL libs or only those that got changed? Does this make a difference for our packagers? Does it make it more difficult or more easy? So is that a feature we want or not? The same naturally goes for stuff like kdeedu now that it split. What if some application got no commits since the last minor release. Make a release anyway or skip it? For major releases i guess making a package anyway makes sense. Or not? -- Michael Jansen http://michael-jansen.biz___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Monday, June 25, 2012 01:16:05 AM Albert Astals Cid wrote: > That works fine for me, though unfortunately we usually have to re-package > some tarballs due to fixes that are needed into the release. How do you fit > this particularity into this way of working? With my config manager head on i say "NEVER rerelease a version". Which in our case includes everything that has been downloaded/used by anone not you (You=Packager). For KDE would say someone else should decide. We could make a release 4.8.80.1 if we have to repackage stuff. But the packagers distros should give input here. I think they should say what is the easiest for them to handle. > > I see one problem. As you can see the changed version information is only > > committed AFTER build and test in this setup. That can take quite some > > time. In a project as big as ours that opens the possibility that during > > that time some else commits a change. Which makes it impossible for the > > script to commits its change. > > > > 1. Solution: Branch. The Script could create a branch for the release. > > Creating a branch for release would also probably "fix" the problem i spoke > in the previous paragraph You mean the repackaging? I am btw. wondering that noone objected yet to this. I seem to remember someone was unhappy about dirk branching some 4.8.x release. I don't remember where and why. > > 2. Solution: Lock the repo (A no go in my opinion) > > Yeah, locking kills babies > > > And a little problem. The feasability of beeing able to build our software > > before packaging. I already have a solution to build the packages with > > build- tool as a test. But no idea yet how to combine build-tool with this > > script unless i add this into build-tool. And the admins would like to > > have > > python. Not ruby. And build-tool would not mash with the idea to use > > jenkins to trigger the releases. > > "this script" == maven? I will not use maven. I just steal some workflow there. This script is the script which we currently try to hammer out how it should work. > > 4. Allow the script to maintain the version increase. We have to decide > > how > > to solve the race condition inherent in this. > > Don't understand what you mean by this. The race condition here is the part where i talked about the script checking out some sources. Working for two hours (compiling, testing, packaging) and then wanting to commit its changes. When someone else committed something in that time it cannot do that on our KDE/4.x branch. The solution i prefer would be to create a KDE/4.x.3 branch and commit there. But that probably breaks ~/ws/src/KDE/kdelibs : git describe v4.8.90-26-g1dd5c9d Which i personally do not care about. I won't stop doing the right thing because it is inconvenient. > In general it seems a very well though out proposal, i don't see any obvious > problem in what you are describing. > > One thing that is problematic with the current build scripts is the need of > having up to date meinproc+kdoctools to build the packages that come after > kdelibs, do you think that'd be an issue? Not really. Because this script will not care. It only releases for now. The build-tool recipe i develop for example would take care of that. It could download and install the required version before going to work on the release packages. Like it can do with soprano, sip, pyqt4, sdo ... . Btw. the script will only tag if you ask it too. I still remember your work- flow of packaging stuff a week before the release date and then on release date only repackage stuff that got changes during that time. That has to be supported by the script. Mike___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Monday 25 June 2012 01:16:05 Albert Astals Cid wrote: > > If we really want to decouple our releases and be more flexible with doing > > them i consider this change a requirement for any decision in that regard. > > > > > > > > Each and every module has to have its own version number build in. I guess > > with the frameworks branch much of kdelibs already got that change (no > > idea > > really, anyone with input?). But we have to do the same with the rest of > > our modules. > > No idea about frameworks. David? Kevin? This is partly still under discussion. However the currently implemented solution is that each framework has a versions number, but that version number can be upgraded in all frameworks at the same time, using a script. A future framework on top of all others, could provide the version number for all apps, much like the current kdeversion.h. Basically it would be the "SC" number, and not the version number of the libs themselves, as is currently the case. -- 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: Release Script
El Dimecres, 20 de juny de 2012, a les 21:30:23, Michael Jansen va escriure: > Hi Hi > > I started to work on some script to help with our release creation and > studied both dirks and allens scripts for input. But the recent discussion > and my personal experience in doing releases (working as a software > configuration manager) made me realize i (or better we) should take a step > back and think about that process first before scripting it. > > This is the chance and perfect time to solve the release problem once and > for all. There are quite some people aware there is room for improvements > and there currently is a lot of discussion and action going on. > > The biggest tool out there used by thousands of hobby programmes and big > corporations to build, release, package, test and deploy stuff is maven. > While it is not a perfect tool in any sence (Don't ever get me started on > that) it has some nice little features we should strive to copy. When > needed i will talk about that. > > WHICH VERSION TO BUILD? > > This is the biggest concern I have with out current release setup. A lot of > our packages contain no version information apart from the name of the build > package (kdebase-4.8.3.tgz). I consider that an absolute no go. But the > thing that strikes me even more wrong is that building kdepim 4.2 against > kdelibs 4.9 leads to libraries named libakregatorprivate.so.4.9.0 . Yes, that's very bad > If we really want to decouple our releases and be more flexible with doing > them i consider this change a requirement for any decision in that regard. > > Each and every module has to have its own version number build in. I guess > with the frameworks branch much of kdelibs already got that change (no idea > really, anyone with input?). But we have to do the same with the rest of our > modules. No idea about frameworks. David? Kevin? > > The version has to live in one agreed upon place in all modules we have. The > release script will know where to look for it, how to parse it, increase > it. That way it is possible to say build the next minor release and the > script will do the rest. If we are going to make releases of different stuff at different times as it was suggested i guess this is mandatory. > > Maven works like that: > > Current Version: 4.7.1-SNAPSHOT (in pom.xml) | Task: Build a minor release > > 1. Checkout sources and change 4.7.1-SNAPSHOT in pom.xml to 4.7.1 > 2. Build, run test and other needed stuff. > 3. If successfully commit the changed version of pom.xml > 4. Make the tag MY_PROJECT-4.7.1 (or whatever) > 5. change 4.7.1 in pom.xml to 4.7.2-SNAPSHOT > > The last step is done in maven because the support something called snapshot > release which means their version looks like 4.7.1-20120621_151400. I think > it could make sense to support that too. Stuff build from master or branch > would be easily distuinguishable from really released stuff. That works fine for me, though unfortunately we usually have to re-package some tarballs due to fixes that are needed into the release. How do you fit this particularity into this way of working? > > The other thing to notice is that there was exactly one version having the > released version number. No possibility for any kind of confusion there. > > I see one problem. As you can see the changed version information is only > committed AFTER build and test in this setup. That can take quite some time. > In a project as big as ours that opens the possibility that during that > time some else commits a change. Which makes it impossible for the script > to commits its change. > > 1. Solution: Branch. The Script could create a branch for the release. Creating a branch for release would also probably "fix" the problem i spoke in the previous paragraph > > 2. Solution: Lock the repo (A no go in my opinion) Yeah, locking kills babies > And a little problem. The feasability of beeing able to build our software > before packaging. I already have a solution to build the packages with > build- tool as a test. But no idea yet how to combine build-tool with this > script unless i add this into build-tool. And the admins would like to have > python. Not ruby. And build-tool would not mash with the idea to use > jenkins to trigger the releases. "this script" == maven? > But i will make sure it is possible to do the release without building (for > emergencies) by calling just one script. > > WHERE IS THE RELEASE CONFIG? > > We currently have our release configuration outside of our source code. > Neatly packed away into (currently) the kde-commons subversion module. > > Maven uses a xml file located inside the sources to find out how it is > supposed to build the package. With configuration i mean > - the current version number > - the versioning number scheme, > - possible hooks into the release process (additional non standard stuff > to execute during the release process) > - what to pack > - what to
Re: Release Script
On Thursday, June 21, 2012 08:44:09 PM Andreas Pakulat wrote: > Hi, > > On Thu, Jun 21, 2012 at 7:58 PM, Michael Jansen wrote: > > ** > > > > On Wednesday, June 20, 2012 11:56:51 PM Andreas Pakulat wrote: > > > Hi, > > > > > > > > > > > > On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen > > > > >wrote: > > > > 2. Make the necessary build-system changes to use this version > > > > information > > > > > > for the .SO names. > > > > > > IMHO this is wrong, the numbers tagged to the end of a shared-object > > > > thats > > > > > used as a shared library really have nothing to do with the release > > > > version > > > > > number. The number is only used to distinguish compatibility of > > > different > > > > > > release of the same library. > > > > I do not disagree. But this is how it is currently done unless i am > > mistaken. Which is certainly possible. > > > > > > > > So unless someone comes up with a better solution or explains why and how > > i am wrong i will keep that because i am pretty sure requiring people to > > manually update the soname for each release is a recipe to disaster and a > > way to annoy our packagers. > > > > > > > > But if you have a solution or idea for that? Keep it coming. We could > > define the soversion too in that configuration file. But how and when to > > increase? On each major and minor release increase it automatically too? > > > > > > > > Btw. kdelibs/cmake/modules/KDE4Defaults.cmake:22 ++ > > > > > And you cannot really go back to 4.2.0 now that 4.9.0 is going to be > > > > > > released. The only option would be to move forward to 5.2.0. So still no > > > > > > exact match between release-version and soname. > > > > I don't want to go back. kdepim4.x will always use the kdelibs versions > > for its soname and not its own version. Unless we rerelease it i can't and > > don't want to change that. > > > > > > > > So the sonames we are talking of are 4.1x or 5.0 depending on the versions > > we put the changes live. > > Hmm, I may have to retract here, it seems my mail was led by false > assumptions based on the shared libs I have here. > > So, I now think that generating the second and third digit of the version > from a file automatically, so it matches the minor and bugfix version of > the project that the shared library belongs to is just fine. As far as I > can see from > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html the > soversion and the first digit of the three-digit version number need to > match. Since you don't want to update the soversion automatically as it has > far-reaching consequences to do that, that part should not be > auto-generated for the VERSION property. So read out minor and bugfix > version and append that to the SOVERSION property to create a value for > VERSION in cmake. And i am a bit confused too. As svuorela pointed out: objdump -x /kde4/kde/lib64/libkdepim-copy.so.4.8.0 | grep SONAME SONAME libkdepim-copy.so.4 lrwxrwxrwx 1 mjansen users 19 May 23 19:31 /kde4/kde/lib64/libkdepim-copy.so -> libkdepim-copy.so.4 lrwxrwxrwx 1 mjansen users 23 May 23 19:31 /kde4/kde/lib64/libkdepim-copy.so.4 -> libkdepim-copy.so.4.8.0 -rwxr-xr-x 1 mjansen users 883382 Jun 16 22:32 /kde4/kde/lib64/libkdepim-copy.so.4.8.0 So i am not so sure about that stuff anymore. Or better i wasn't to start with. Anyway i don't want to change anything there. I just wanted to point out that reusing the number from kde4defaults.cmake should not be done for our packages. Each package should have each needed version information itself. Because only that makes it possible to skip releases and release independently. Mike ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
On Wednesday, June 20, 2012 11:56:51 PM Andreas Pakulat wrote: > Hi, > > On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen wrote: > > 2. Make the necessary build-system changes to use this version information > > for the .SO names. > > IMHO this is wrong, the numbers tagged to the end of a shared-object thats > used as a shared library really have nothing to do with the release version > number. The number is only used to distinguish compatibility of different > release of the same library. I do not disagree. But this is how it is currently done unless i am mistaken. Which is certainly possible. So unless someone comes up with a better solution or explains why and how i am wrong i will keep that because i am pretty sure requiring people to manually update the soname for each release is a recipe to disaster and a way to annoy our packagers. But if you have a solution or idea for that? Keep it coming. We could define the soversion too in that configuration file. But how and when to increase? On each major and minor release increase it automatically too? Btw. kdelibs/cmake/modules/KDE4Defaults.cmake:22 ++ > And you cannot really go back to 4.2.0 now that 4.9.0 is going to be > released. The only option would be to move forward to 5.2.0. So still no > exact match between release-version and soname. I don't want to go back. kdepim4.x will always use the kdelibs versions for its soname and not its own version. Unless we rerelease it i can't and don't want to change that. So the sonames we are talking of are 4.1x or 5.0 depending on the versions we put the changes live. -- Michael Jansen http://michael-jansen.biz___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Hi, On Thu, Jun 21, 2012 at 8:57 PM, Michael Jansen wrote: > ** > > On Thursday, June 21, 2012 08:44:09 PM Andreas Pakulat wrote: > > > Hi, > > > > > > On Thu, Jun 21, 2012 at 7:58 PM, Michael Jansen >wrote: > > > > ** > > > > > > > > On Wednesday, June 20, 2012 11:56:51 PM Andreas Pakulat wrote: > > > > > Hi, > > > > > > > > > > > > > > > > > > > > On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen < > i...@michael-jansen.biz > > > > > > > > > >wrote: > > > > > > 2. Make the necessary build-system changes to use this version > > > > > > > > information > > > > > > > > > > for the .SO names. > > > > > > > > > > IMHO this is wrong, the numbers tagged to the end of a shared-object > > > > > > > > thats > > > > > > > > > used as a shared library really have nothing to do with the release > > > > > > > > version > > > > > > > > > number. The number is only used to distinguish compatibility of > > > > > different > > > > > > > > > > release of the same library. > > > > > > > > I do not disagree. But this is how it is currently done unless i am > > > > mistaken. Which is certainly possible. > > > > > > > > > > > > > > > > So unless someone comes up with a better solution or explains why and > how > > > > i am wrong i will keep that because i am pretty sure requiring people > to > > > > manually update the soname for each release is a recipe to disaster > and a > > > > way to annoy our packagers. > > > > > > > > > > > > > > > > But if you have a solution or idea for that? Keep it coming. We could > > > > define the soversion too in that configuration file. But how and when > to > > > > increase? On each major and minor release increase it automatically > too? > > > > > > > > > > > > > > > > Btw. kdelibs/cmake/modules/KDE4Defaults.cmake:22 ++ > > > > > > > > > And you cannot really go back to 4.2.0 now that 4.9.0 is going to be > > > > > > > > > > released. The only option would be to move forward to 5.2.0. So > still no > > > > > > > > > > exact match between release-version and soname. > > > > > > > > I don't want to go back. kdepim4.x will always use the kdelibs versions > > > > for its soname and not its own version. Unless we rerelease it i can't > and > > > > don't want to change that. > > > > > > > > > > > > > > > > So the sonames we are talking of are 4.1x or 5.0 depending on the > versions > > > > we put the changes live. > > > > > > Hmm, I may have to retract here, it seems my mail was led by false > > > assumptions based on the shared libs I have here. > > > > > > So, I now think that generating the second and third digit of the version > > > from a file automatically, so it matches the minor and bugfix version of > > > the project that the shared library belongs to is just fine. As far as I > > > can see from > > > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html the > > > soversion and the first digit of the three-digit version number need to > > > match. Since you don't want to update the soversion automatically as it > has > > > far-reaching consequences to do that, that part should not be > > > auto-generated for the VERSION property. So read out minor and bugfix > > > version and append that to the SOVERSION property to create a value for > > > VERSION in cmake. > > > > And i am a bit confused too. As svuorela pointed out: > > > > objdump -x /kde4/kde/lib64/libkdepim-copy.so.4.8.0 | grep SONAME > > SONAME libkdepim-copy.so.4 > The tldp link I included has a rather easy to understand explanation close to the top about this. > lrwxrwxrwx 1 mjansen users 19 May 23 19:31 > > /kde4/kde/lib64/libkdepim-copy.so -> libkdepim-copy.so.4 > > lrwxrwxrwx 1 mjansen users 23 May 23 19:31 > > /kde4/kde/lib64/libkdepim-copy.so.4 -> libkdepim-copy.so.4.8.0 > > -rwxr-xr-x 1 mjansen users 883382 Jun 16 22:32 > > /kde4/kde/lib64/libkdepim-copy.so.4.8.0 > > > > So i am not so sure about that stuff anymore. Or better i wasn't to start > with. > As I said, right now most libs are at BC-version 4 (some kdelibs libs like kdecore are already at BC version 5) and so far the minor version and a .0 was simply added to get the 'realname' (as tldp puts it). > Anyway i don't want to change anything there. I just wanted to point out > that reusing the number from kde4defaults.cmake should not be done for our > packages. > > > > Each package should have each needed version information itself. Because > only that makes it possible to skip releases and release independently. > Yes, if releasing projects indepentenly from one another is the goal, then each needs to maintain its own SOVERSION and VERSION. FWIW some projects already do this, kdevplatform for example is at SOVERSION 6 now in master and kdegames also had two BC breakages since 2.0 I believe so it should also be at 6 (didn't actually check and am not 100% sure). Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Hi, On Thu, Jun 21, 2012 at 7:58 PM, Michael Jansen wrote: > ** > > On Wednesday, June 20, 2012 11:56:51 PM Andreas Pakulat wrote: > > > Hi, > > > > > > On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen >wrote: > > > > 2. Make the necessary build-system changes to use this version > information > > > > for the .SO names. > > > > > > IMHO this is wrong, the numbers tagged to the end of a shared-object > thats > > > used as a shared library really have nothing to do with the release > version > > > number. The number is only used to distinguish compatibility of different > > > release of the same library. > > > > I do not disagree. But this is how it is currently done unless i am > mistaken. Which is certainly possible. > > > > So unless someone comes up with a better solution or explains why and how > i am wrong i will keep that because i am pretty sure requiring people to > manually update the soname for each release is a recipe to disaster and a > way to annoy our packagers. > > > > But if you have a solution or idea for that? Keep it coming. We could > define the soversion too in that configuration file. But how and when to > increase? On each major and minor release increase it automatically too? > > > > Btw. kdelibs/cmake/modules/KDE4Defaults.cmake:22 ++ > > > > > And you cannot really go back to 4.2.0 now that 4.9.0 is going to be > > > released. The only option would be to move forward to 5.2.0. So still no > > > exact match between release-version and soname. > > > > I don't want to go back. kdepim4.x will always use the kdelibs versions > for its soname and not its own version. Unless we rerelease it i can't and > don't want to change that. > > > > So the sonames we are talking of are 4.1x or 5.0 depending on the versions > we put the changes live. > Hmm, I may have to retract here, it seems my mail was led by false assumptions based on the shared libs I have here. So, I now think that generating the second and third digit of the version from a file automatically, so it matches the minor and bugfix version of the project that the shared library belongs to is just fine. As far as I can see from http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html the soversion and the first digit of the three-digit version number need to match. Since you don't want to update the soversion automatically as it has far-reaching consequences to do that, that part should not be auto-generated for the VERSION property. So read out minor and bugfix version and append that to the SOVERSION property to create a value for VERSION in cmake. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Script
Hi, On Wed, Jun 20, 2012 at 9:30 PM, Michael Jansen wrote: > > 2. Make the necessary build-system changes to use this version information > for the .SO names. > IMHO this is wrong, the numbers tagged to the end of a shared-object thats used as a shared library really have nothing to do with the release version number. The number is only used to distinguish compatibility of different release of the same library. And you cannot really go back to 4.2.0 now that 4.9.0 is going to be released. The only option would be to move forward to 5.2.0. So still no exact match between release-version and soname. Andreas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
