release: version bumps for 12.0 alpha1 #815

Merged
merged 1 commit into from Apr 4, 2012

Conversation

Projects
None yet
6 participants
@theuni
Member

theuni commented Mar 26, 2012

This needs to go in before much else...

These are the standard bumps, and the new one that keeps xbmc.addon inline.

@jmarshallnz

This comment has been minimized.

Show comment Hide comment
@jmarshallnz

jmarshallnz Mar 26, 2012

Member

One thing to consider is what should we do (if anything) if we want monthlies, in the remote possibility that the monthly merge thing works out?

Member

jmarshallnz commented Mar 26, 2012

One thing to consider is what should we do (if anything) if we want monthlies, in the remote possibility that the monthly merge thing works out?

@theuni

This comment has been minimized.

Show comment Hide comment
@theuni

theuni Mar 26, 2012

Member

seeing as we've never really used point versions (except for 10.1 which would fall under the same category), seems like they'd fit the bill to me? If so, I can't think of any changes needed here.

Member

theuni commented Mar 26, 2012

seeing as we've never really used point versions (except for 10.1 which would fall under the same category), seems like they'd fit the bill to me? If so, I can't think of any changes needed here.

@jmarshallnz

This comment has been minimized.

Show comment Hide comment
@jmarshallnz

jmarshallnz Mar 26, 2012

Member

So an April 2012 release would be 12.04?

Member

jmarshallnz commented Mar 26, 2012

So an April 2012 release would be 12.04?

@malard

This comment has been minimized.

Show comment Hide comment
@malard

malard Mar 26, 2012

Member

why not just 12.1, 12.2 etc, then we don't end up with confusion if people go I want 12.3 and we didn't release in march but we did for every other month that year

Member

malard commented Mar 26, 2012

why not just 12.1, 12.2 etc, then we don't end up with confusion if people go I want 12.3 and we didn't release in march but we did for every other month that year

@theuni

This comment has been minimized.

Show comment Hide comment
@theuni

theuni Mar 26, 2012

Member

Yea, I meant what @malard said. Point-releases per merge window, full releases get a major bump.

Member

theuni commented Mar 26, 2012

Yea, I meant what @malard said. Point-releases per merge window, full releases get a major bump.

@theuni

This comment has been minimized.

Show comment Hide comment
@theuni

theuni Mar 26, 2012

Member

So I guess these should be 11.1 then. How much confidence to we have in this for the first go at it? :p

Member

theuni commented Mar 26, 2012

So I guess these should be 11.1 then. How much confidence to we have in this for the first go at it? :p

@Memphiz

This comment has been minimized.

Show comment Hide comment
@Memphiz

Memphiz Mar 26, 2012

Member

Mhhh shouldn't we bump versions to 11.0 instead of 12.0? Looking at ios it was on 10.0-9 or so until eden was released. Why bumping to 12.0 now?

Member

Memphiz commented Mar 26, 2012

Mhhh shouldn't we bump versions to 11.0 instead of 12.0? Looking at ios it was on 10.0-9 or so until eden was released. Why bumping to 12.0 now?

@theuni

This comment has been minimized.

Show comment Hide comment
@theuni

theuni Mar 26, 2012

Member

@Memphiz ios wasn't bumped in master, only in Eden. It was released as 11.0.

See here: 04d4066

Member

theuni commented Mar 26, 2012

@Memphiz ios wasn't bumped in master, only in Eden. It was released as 11.0.

See here: 04d4066

@jmarshallnz

This comment has been minimized.

Show comment Hide comment
@jmarshallnz

jmarshallnz Mar 26, 2012

Member

That's what I was getting at - if we want 11.foo, then bumping to 12 right now is probably not the way to go :)

And about 3% confident :p

Member

jmarshallnz commented Mar 26, 2012

That's what I was getting at - if we want 11.foo, then bumping to 12 right now is probably not the way to go :)

And about 3% confident :p

@theuni

This comment has been minimized.

Show comment Hide comment
@theuni

theuni Mar 27, 2012

Member

Updated for 11.1, and got configure.in which i missed the first time.

I think this is the most sane way to go. We can always change our minds and bump to 12.0 later if needed, but we can't go backwards.

Member

theuni commented Mar 27, 2012

Updated for 11.1, and got configure.in which i missed the first time.

I think this is the most sane way to go. We can always change our minds and bump to 12.0 later if needed, but we can't go backwards.

@Montellese

This comment has been minimized.

Show comment Hide comment
@Montellese

Montellese Mar 27, 2012

Member

Would those monthlies be considered "stable" or just a special semi-stable release? Just asking because of the addon repo, addon versions and jsonrpc version.

Member

Montellese commented Mar 27, 2012

Would those monthlies be considered "stable" or just a special semi-stable release? Just asking because of the addon repo, addon versions and jsonrpc version.

@jmarshallnz

This comment has been minimized.

Show comment Hide comment
@jmarshallnz

jmarshallnz Mar 27, 2012

Member

I think the first few will be considered slightly more stable than nightlies until we get an idea of how well it will work. i.e. they'll be released as alpha quality most likely, so using frodo-pre for the add-on repo seems like the way to go.

Member

jmarshallnz commented Mar 27, 2012

I think the first few will be considered slightly more stable than nightlies until we get an idea of how well it will work. i.e. they'll be released as alpha quality most likely, so using frodo-pre for the add-on repo seems like the way to go.

@NedScott

This comment has been minimized.

Show comment Hide comment
@NedScott

NedScott Mar 27, 2012

Contributor

v12 Alpha 1, v12 Alpha 2, etc ?

Since all these lead up to a final (more stable) version that will be called v12.

I think we should avoid calling them v11.whatever if there are going to be semi-stable releases of any kind, since people have it in their heads that v11 will still support things like Mac OS 10.4, etc.

Contributor

NedScott commented Mar 27, 2012

v12 Alpha 1, v12 Alpha 2, etc ?

Since all these lead up to a final (more stable) version that will be called v12.

I think we should avoid calling them v11.whatever if there are going to be semi-stable releases of any kind, since people have it in their heads that v11 will still support things like Mac OS 10.4, etc.

@jmarshallnz

This comment has been minimized.

Show comment Hide comment
@jmarshallnz

jmarshallnz Mar 31, 2012

Member

I don't have a problem with 12~alpha1 if that is deemed the way to go. I guess it perhaps satisfies the idea of monthlies being semi-stable pre-releases of the next stable.

Member

jmarshallnz commented Mar 31, 2012

I don't have a problem with 12~alpha1 if that is deemed the way to go. I guess it perhaps satisfies the idea of monthlies being semi-stable pre-releases of the next stable.

@theuni

This comment has been minimized.

Show comment Hide comment
@theuni

theuni Mar 31, 2012

Member

I would personally prefer not to have Alpha or Beta vesions floating around if there's not actually a release schedule planned yet. Alpha/Beta/RC have meaning to people, and will get reported on whether they match what we're doing or not.

My primary reason for using .1 rather than .alpha was related to sorting. Typically, non-numerical version-sorting is frowned upon by packagers. Though, we're free to call the thing whatever we want. just because it's xbmc-12-foo^bar~ doesn't mean we have to refer to it that way.

A few models to consider:

  • The linux kernel uses X.0-rcY notation, until the rc is dropped. In our case, that would mean 12.0-rc1 would be entirely unstable, where 12.0 is the final stable in the series. The number of rc's is variable and somewhat random, for us each would represent a merge window
  • Many libs will use 11.9.x.y to mean pre-12.0. 11.9.0 could mean the first merge window in the cycle, 11.9.1 would be the second window, etc until 12.0 for the final release.

I'm rather partial to the first, myself. I realize I've contradicted myself by simultaneously saying we shouldn't arbitrarily be calling live dev branches alpha/beta/rc, but it seems to work quite well for Linux. Ofcourse the difference for us is that we'll have multiple windows per stable release. Tbh I really have no solution there...

Member

theuni commented Mar 31, 2012

I would personally prefer not to have Alpha or Beta vesions floating around if there's not actually a release schedule planned yet. Alpha/Beta/RC have meaning to people, and will get reported on whether they match what we're doing or not.

My primary reason for using .1 rather than .alpha was related to sorting. Typically, non-numerical version-sorting is frowned upon by packagers. Though, we're free to call the thing whatever we want. just because it's xbmc-12-foo^bar~ doesn't mean we have to refer to it that way.

A few models to consider:

  • The linux kernel uses X.0-rcY notation, until the rc is dropped. In our case, that would mean 12.0-rc1 would be entirely unstable, where 12.0 is the final stable in the series. The number of rc's is variable and somewhat random, for us each would represent a merge window
  • Many libs will use 11.9.x.y to mean pre-12.0. 11.9.0 could mean the first merge window in the cycle, 11.9.1 would be the second window, etc until 12.0 for the final release.

I'm rather partial to the first, myself. I realize I've contradicted myself by simultaneously saying we shouldn't arbitrarily be calling live dev branches alpha/beta/rc, but it seems to work quite well for Linux. Ofcourse the difference for us is that we'll have multiple windows per stable release. Tbh I really have no solution there...

@jmarshallnz

This comment has been minimized.

Show comment Hide comment
@jmarshallnz

jmarshallnz Mar 31, 2012

Member

Well, given that we're just pissing around choosing colours here, why not just make a call and push it in :)

Member

jmarshallnz commented Mar 31, 2012

Well, given that we're just pissing around choosing colours here, why not just make a call and push it in :)

@Memphiz

This comment has been minimized.

Show comment Hide comment
@Memphiz

Memphiz Mar 31, 2012

Member

i like blue and red - and boblight color :)

Member

Memphiz commented Mar 31, 2012

i like blue and red - and boblight color :)

@theuni

This comment has been minimized.

Show comment Hide comment
@theuni

theuni Apr 1, 2012

Member

Ok, after a discussion on irc, I think we've come to a consensus with using -alpha notation for the merge windows. Green it is ;)

We'll call our current dev 12.0-alpha1, It will become 12.0-alpha2 when the next merge window opens. This allows for a 12.0 rcX stage before final 12.0 stable release.

I had to go with 11.9.x for the places where "alpha" can't be used (addon.xml and configure.in). As these are not user-facing, I don't see any problems with that.

I'm planning to push this in tomorrow.

Member

theuni commented Apr 1, 2012

Ok, after a discussion on irc, I think we've come to a consensus with using -alpha notation for the merge windows. Green it is ;)

We'll call our current dev 12.0-alpha1, It will become 12.0-alpha2 when the next merge window opens. This allows for a 12.0 rcX stage before final 12.0 stable release.

I had to go with 11.9.x for the places where "alpha" can't be used (addon.xml and configure.in). As these are not user-facing, I don't see any problems with that.

I'm planning to push this in tomorrow.

@jmarshallnz

This comment has been minimized.

Show comment Hide comment
@jmarshallnz

jmarshallnz Apr 1, 2012

Member

Fine with me

Member

jmarshallnz commented Apr 1, 2012

Fine with me

@jmarshallnz

This comment has been minimized.

Show comment Hide comment
@jmarshallnz

jmarshallnz Apr 3, 2012

Member

There's some more in XBMC_PC.rc:

FILEVERSION 10,05,0,0
PRODUCTVERSION 10,05,0,0

Member

jmarshallnz commented Apr 3, 2012

There's some more in XBMC_PC.rc:

FILEVERSION 10,05,0,0
PRODUCTVERSION 10,05,0,0

@theuni

This comment has been minimized.

Show comment Hide comment
@theuni

theuni Apr 3, 2012

Member

Looks like those haven't been bumped in a while, I'm assuming they define the application metadata in file/properties?

Fixed either way.

Member

theuni commented Apr 3, 2012

Looks like those haven't been bumped in a while, I'm assuming they define the application metadata in file/properties?

Fixed either way.

theuni
release: version bumps for 12.0 alpha1
Each merge window will be defined as an alpha release. Thus, the first commit
in the next merge window should be a bump to 12.0 alpha2.

For internal versioning that cannot be handled with strings, we use currentvers + .9 instead, so that versions are always incrementing. It's not nice to mix, but since they're for dev use only, confusion should be minimal.

xbmc.addon will be 11.9.1 for the first alpha in the 12.0 release series, 11.9.2 for the second, etc. This way final release will be 12.0.0 as expected. configure.in is handled the same way.

theuni added a commit that referenced this pull request Apr 4, 2012

Merge pull request #815 from theuni/versionbump
release: version bumps for 12.0 alpha1

@theuni theuni merged commit bf6d2ea into xbmc:master Apr 4, 2012

ksooo referenced this pull request in metaron-uk/xbmc Sep 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment