| OvenWerks | Eickmeyer: moving a version to the next release before full release means the auto build may be chosen instead of the next release | 02:05 |
|---|---|---|
| Eickmeyer | OvenWerks: I'm having difficulty seeing how that would be a problem if you're subscribed to the autobuilds. | 02:53 |
| Eickmeyer | I mean, obviously we wouldn't want it to move forward unless we've made changes that need testing. | 02:54 |
| OvenWerks | Eickmeyer: even when the release is exactly the same as the autobuild/backport the release is the one that should be installed as latest. | 04:32 |
| OvenWerks | Otherwise there is confusion, it seems that the user ended up with a patched version when in fact they have a released version | 04:33 |
| OvenWerks | backport would of course be the same as release... I think I got that wrong. But in that case it should also be named the same as release anyway because it is a release | 04:34 |
| OvenWerks | Eickmeyer: having said that, in the case of back ports, if we use yy.mo.s would that aslo cause trouble to someone who has version 19.10 of controls (for example) installed with US 19.04? | 04:38 |
| OvenWerks | I guess if it is well known that is ok. | 04:39 |
| Eickmeyer[m] | Not at all. The build system in Launchpad appends yy.mm of the target to the package. I could’ve sworn we already had this conversation. | 04:40 |
| OvenWerks | nope not with me... or at least not exactly :) | 04:40 |
| Eickmeyer[m] | So, a back port of ubuntustudio-controls 19.10 to 19.04 would show up as 19.10-0ubuntu19.04. | 04:42 |
| OvenWerks | That be ok. I remember talking about this before now | 04:42 |
| Eickmeyer[m] | :) | 04:43 |
| OvenWerks | but I was thinking about it from a different angle this time so it seemed different | 04:43 |
| Eickmeyer[m] | Got it. | 04:43 |
| OvenWerks | Anyway, my first point is still valid. | 04:44 |
| OvenWerks | I would suggest all releases be yy.mm with the iso release and WIP beta be last yy.mm.1 with the date appended. | 04:45 |
| OvenWerks | That way the next release is always higher version than autobuilds | 04:46 |
| OvenWerks | and autobuilds are always higher version than last release | 04:46 |
| Eickmeyer[m] | Yes, as it should be. Remember also, I’m not let anything build to backports unless it is a full release or an SRU. | 04:47 |
| Eickmeyer[m] | *letting | 04:47 |
| OvenWerks | If we need a backport mid way in between two releases, just use whatever that month is so 19.06 is needed | 04:47 |
| OvenWerks | s/is/if/ | 04:48 |
| Eickmeyer[m] | If that were the case, it would be 19.04.1, not 19.06. | 04:48 |
| Eickmeyer[m] | Remember, the yy.mm is always the target, the .s is for minor releases. | 04:50 |
| OvenWerks | Hmm, that leaves us with thesame problem. | 04:51 |
| Eickmeyer[m] | If you have the autobuild PPA, the autobuild version should always be the version you have, right? | 04:53 |
| Eickmeyer[m] | Same with backports. | 04:54 |
| OvenWerks | if there is a new release no | 04:54 |
| OvenWerks | Any time there is a release that is the same as autobuild, the release should be considered latest | 04:54 |
| OvenWerks | backports are releases. | 04:55 |
| Eickmeyer[m] | Autobuild is taken from master, and release is a snapshot of what is in autobuild essentially. | 04:55 |
| OvenWerks | yes, but that doesn't change things, if I ask someone what version of SW do you have, I should get a release version if there is one available | 04:56 |
| OvenWerks | if I get an autobuild version I assume it is alpha or beta not release | 04:57 |
| Eickmeyer[m] | I kinda see what you’re saying. | 04:59 |
| OvenWerks | I think +git or even +B or +beta would be right | 04:59 |
| OvenWerks | +git means where master is right now | 05:00 |
| Eickmeyer[m] | I corrected the recipe for -menu to be +git earlier today as you asked. Did you mean -menu-add? Because I didn’t touch that one. | 05:00 |
| OvenWerks | So if the last release was 19.04 then a beta would be 19.04+git | 05:01 |
| OvenWerks | -menu is correct | 05:02 |
| Eickmeyer[m] | Yes, but I would make it 19.04.0+git leaving the .0 for in case I (or Ross) had to do any extra uploads for bug fixes during a freeze. | 05:03 |
| Eickmeyer[m] | Forget it. I’ll leave things how they are. | 05:04 |
| OvenWerks | Ok, then the change log would have to be changed to add the .0 I think | 05:04 |
| OvenWerks | Other wise the recipe would have to be changed if we got to .1 | 05:04 |
| Eickmeyer[m] | Yes. Any versioning would have to be done directly in the change log. | 05:05 |
| Eickmeyer[m] | I’ll explain more in the morning. I had a long weekend and am in bed now. | 05:06 |
| OvenWerks | Sorry. | 05:06 |
| OvenWerks | gn | 05:06 |
| * OvenWerks still has to pick his Yf up later | 05:07 | |
| Eickmeyer[m] | No worries. I might have to make it an email. | 05:07 |
| OvenWerks | menu-add doesn't have a recipe. | 05:07 |
| OvenWerks | which is good. | 05:07 |
| Eickmeyer | OvenWerks: I think we'll just leave the version numbers the same now for the sake of simplicity. I get that it can cause confusion. | 20:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!