Subject: Lotsa numbers

From: Daniel van Vugt <[email-masked]>
Date: Wed, 11 Dec 2013 15:24:06 +0800

The current archive release of Mir is:
     0.1.2+14.04.20131128.1-0ubuntu2

But do we really need to keep all that  date info? Surely all we really 
want is:
     0.1.2-0ubuntu2

It's just as unique, and less a jumble of numbers. It might also stop 
Launchpad from complaining:
     "Mir 0.1.2 is older than the current packaged version"...

- Daniel

---

From: Kevin Gunn <[email-masked]>
Date: Wed, 11 Dec 2013 12:46:21 -0600

Hey Daniel -
I'm certainly not opposed..
I can't remember exactly why, but I believe its the release teams process
to add the date in when they insert it into archive.

Didrocks ?

br,kg

On Wed, Dec 11, 2013 at 1:24 AM, Daniel van Vugt <
[email-masked]> wrote:

> --
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>

---

From: Michał Sawicz <[email-masked]>
Date: Wed, 11 Dec 2013 20:51:07 +0100

On 11.12.2013 19:46, Kevin Gunn wrote:
> I can't remember exactly why, but I believe its the release teams
> process to add the date in when they insert it into archive.

Upstream_Version+Target_Release.Date[.Iteration]

AFAICT the purpose was to be able to easily determine what the package 
really is - as in what it's targeted for (14.04) and the unique release 
date (+optional iteration, if there were two on the same day).

On top of that, 0.1.2 alone can't be the upstream version number, as 
code changes would be rejected by dpkg - you can't have two upstream 
.orig tarballs with different contents (that generally excludes the 
debian/ folder).

-- 
Michał (Saviq) Sawicz <[email-masked]>
Canonical Services Ltd.

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 12 Dec 2013 09:19:12 +0800

"0.1.2" is the upstream version number, and there is only one tarball;
   https://launchpad.net/mir/+milestone/0.1.2

I'm not sure where the suggestion of multiple upstream tarballs comes from.

For iterations between upstream releases, we have the -NubuntuM suffix. 
That's what it's for (!?).

---

From: Michał Sawicz <[email-masked]>
Date: Thu, 12 Dec 2013 09:20:16 +0100

> I'm not sure where the suggestion of multiple upstream tarballs comes from.

Do you bump the upstream version number between packages into going into 
Ubuntu? As in - is there really only one code tree per-upstream-version?

It's not the case for most other projects under daily release, at least 
- we only bump the version numbers when needed for dependency reasons 
(or well, when it makes sense). Difference is we're not doing dev branch 
vs. trunk, all code goes into trunk, and it's the release team that 
ultimately decides when to release. Sure, we could bump after each 
release, but that's what the automagic release does for us, effectively. 
It's a kind-of-rolling-release scenario for us.

> That's what it's for (!?).

Downstream releases, no? You can't change the upstream code between 
differently-suffixed packages (other than putting patches in debian/, 
that is).

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 12 Dec 2013 16:24:26 +0800

Oh, I see where the confusion is.

No, Mir is not on daily releases because it affects too many other 
projects and we need to manually coordinate ABI/API changes for each 
release. Mir is on weekly-ish releases, all of which have proper version 
numbers. Hence, only one tarball :)

---

From: Michał Sawicz <[email-masked]>
Date: Thu, 12 Dec 2013 09:27:15 +0100

> numbers. Hence, only one tarball :)

So well, yeah, in your case it'd be OK to have a simple version 
number... Don't think the autorelease machinery (that's still used, even 
if kicked off manually) ever planned for that...