On 12.12.2013 09:24, Daniel van Vugt wrote:
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.
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 :)
On 12/12/13
On 12.12.2013 02:19, Daniel van Vugt wrote:
"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.
Do you bump the upstream version number between packages int
"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 (!?).
O
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.
0.1.2+14.04.20131128.1-0ubuntu2
Upstream_Version+Target_Release.Date[.Iteration]
AFAICT the purpose was to be able to easily de
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 <
daniel.van.v...@canonical.com> wrote:
> The current archiv
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 o
