SageTV Open Source Download Area

[mwnswiss]

Yes, we could "persist" the build number in such a service and pull it just from the google repo, that would be my approach to solve it. And the trace to each commit is as well given so we have a full loop. Not perfect but one possible approach

[stuckless]

Originally Posted by mwnswiss

Yes, we could "persist" the build number in such a service and pull it just from the google repo, that would be my approach to solve it. And the trace to each commit is as well given so we have a full loop. Not perfect but one possible approach

But where is the version being persisted?

[mwnswiss]

I only refer to the build number, the Major, Minor, Micro would need manual increments. So "9.0.1" is set manually, but the BUILD_VERSION could be set by the build system and kept on a dummy/placeholder in the github source. You could still add a gradle task or a script to update it if you build on your own. It is not too nice, but still an option.

I wonder if an other approach would be usage of git hooks?

[Narflex]

One other trick I read about which might not be a bad idea is for the script that builds the JAR file to run a git command that counts the number of commit messages; and then use that as the build number. Using "git rev-list HEAD --count" seems like it would work.

[stuckless]

Originally Posted by Narflex

One other trick I read about which might not be a bad idea is for the script that builds the JAR file to run a git command that counts the number of commit messages; and then use that as the build number. Using "git rev-list HEAD --count" seems like it would work.

That's a good idea.

[Monedeath]

Originally Posted by stuckless

Yes, I did not commit the changes back to the SageTV repo for the change that I made to the SageConstants.java, locally. Because the micro version changed to 1, I reset the build back to 0, since this is the first release build, and any change to a MAJOR/MINOR/MICRO should reset the build #. I may just start to build from the OpenSageTV repo (instead of the google repo), and track my own build #s there. The problem with building from the google repo, is that without the ability to directly commit, you can't automate the build # change, but if I build from the OpenSageTV repo, then I can control it.

Either way, are you saying the build # should be have 9.0.1.4?

Well, if you built it right now, a case could probably be made for it being 9.0.2.0.

I do think generally speaking, it is a bad practice to release a new build with a version number lower than a build that is already "out in the wild" particular when that build # came from the main repo. It would become a nightmare to have to figure which 9.0.1.3 version a person was running if the 1.x series persists long enough to get back to 1.3 in your binary repository it begins to become too many things for people to try to track when trying help provide support.

An alterate option is to only reset the build # to 0 when either the major or minor version changes. Although this can result in vary large build # scenarios at some point.

[Fuzzy]

I think going off git numbering is perfectly acceptable, the issue is being able to reset it with minor version changes. You'd have to record the git count of the minor version and subtract it from the current git count to create your build number.

[stuckless]

Originally Posted by Monedeath

Well, if you built it right now, a case could probably be made for it being 9.0.2.0.

I do think generally speaking, it is a bad practice to release a new build with a version number lower than a build that is already "out in the wild" particular when that build # came from the main repo. It would become a nightmare to have to figure which 9.0.1.3 version a person was running if the 1.x series persists long enough to get back to 1.3 in your binary repository it begins to become too many things for people to try to track when trying help provide support.

An alterate option is to only reset the build # to 0 when either the major or minor version changes. Although this can result in vary large build # scenarios at some point.

Well, my previous was 9.0.0.4 and this one was 9.0.1.0... I can't be help what might be in the wild when people can simply fork and build their own versions. Hopefully if someone is asking for support and running a version, they say where they got the version. If they get it from the OpenSageTV repo, the versions will be consistent and ever increasing. ie, there very well be a 9.0.1.3 from OpenSageTV that matches someone else prebuilt version. I can't help that.

All that being said, I think Jeff provided a good solution to this, and I'll use in the next release which is using the # of commits. (I just need to figure out a good way to do it since the last build)

Ideally when the version # changes, the build should be reset. That's not my doing. I didn't increase version #. The build # was the build # from the previous release 9.0.0 and as such it didn't reflect this build, in the new version, and so it got reset.

Is every build a new version? If so, then I guess we should increase the micro version with each new build.

I'm sure we'll figure this out... This is the second build.

[stuckless]

Originally Posted by Fuzzy

I think going off git numbering is perfectly acceptable, the issue is being able to reset it with minor version changes. You'd have to record the git count of the minor version and subtract it from the current git count to create your build number.

I agree... And much of this becomes much simpler when you have access to commit changes back to the repo... such as tags.... but if I could do that, then it would be trivial to record a build # in a file as well.

I'm considering just building from the OpenSageTV repo and just maintaining the build # there. That way, I can update the build tools to publish that information back into the repo.

[Monedeath]

Originally Posted by stuckless

Is every build a new version? If so, then I guess we should increase the micro version with each new build.

No, some builds are bug fixes or performance/behavior tweaks.

So far, the precedent in the repo for changing the micro version from 0 to 1 was:

https://github.com/google/sagetv/com...b47bde1cfa371b

Incremented version
I should have done this when we did the last change since it affected functionality.

..which involved changes as to behavior of carny when it comes to the "don't like" flag and intelligent recordings/favorites recordings.

While today saw
-the introduction of the ability to use longer file names and spaces in file names, among some some other characters. (Can be classed as a tweak rather than a new feature)

-changes to the sage core to create an api call to get/set tuner merit from within the sage ui, as well as a couple tweaks to how capture devices are handled. (Can be classed as a tweak, tuner merit isn't new, only having an api call for being able to adjust it dynamically is new)

Which is why I said a case could be made, not must or should.

[Fuzzy]

Originally Posted by stuckless

I agree... And much of this becomes much simpler when you have access to commit changes back to the repo... such as tags.... but if I could do that, then it would be trivial to record a build # in a file as well.

I'm considering just building from the OpenSageTV repo and just maintaining the build # there. That way, I can update the build tools to publish that information back into the repo.

I guess that would depend on who's ultimately going to be making the decisions on version increments. If Jeff is going to be maintaining control of the main git, than he would need to be the one to handle altering any version settings in that git. Any auto-build scripting would then also need to be done by him, so that permissions could be made to record that information.

[stuckless]

Originally Posted by Fuzzy

I guess that would depend on who's ultimately going to be making the decisions on version increments. If Jeff is going to be maintaining control of the main git, than he would need to be the one to handle altering any version settings in that git. Any auto-build scripting would then also need to be done by him, so that permissions could be made to record that information.

I fully agree, but I don't think Jeff wants to be in charge of doing builds Using a separate repo for builds allows someone else to control the versions, and the auto-build scripting.

[Fuzzy]

Originally Posted by stuckless

I fully agree, but I don't think Jeff wants to be in charge of doing builds Using a separate repo for builds allows someone else to control the versions, and the auto-build scripting.

I guess the worry would be fragmentation if the master was not kept up to date. I'd almost prefer, if you're going to have a fork for the building, that it not accept any pulls, and only get updated from upstream google/sagetv. This would still allow a common, and somewhat regulated location for community contributions, which then could get brought into the 'build' git.

In the future, I can see this happening without Jeff being tied in there, but I think for the early open source lifetime, there is so much code in there that we don't know that it makes sense to have Jeff and Andy an integral part of the process, even if it ends up slowing down getting things implemented and released.

[stuckless]

Originally Posted by Fuzzy

I guess the worry would be fragmentation if the master was not kept up to date. I'd almost prefer, if you're going to have a fork for the building, that it not accept any pulls, and only get updated from upstream google/sagetv. This would still allow a common, and somewhat regulated location for community contributions, which then could get brought into the 'build' git.

In the future, I can see this happening without Jeff being tied in there, but I think for the early open source lifetime, there is so much code in there that we don't know that it makes sense to have Jeff and Andy an integral part of the process, even if it ends up slowing down getting things implemented and released.

The OpenSageTV area would basically rebase itself with the main google repo either for each build, or periodically. But, you are correct, in that things could happen there that would be different than the google repo. For example, if there were changes that we wanted in "core" that Jeff didn't want in his repo, then they could exist there. I don't know off hand what that would be. Lots of projects run this way. Take IntelliJ for example. It has a main product and CE github product. And Android Studio is based off that as well. Each of them has their own repo, but Android Studio will periodically pull changes from the main IntelliJ repo. Intellij will pull changes from the CE area, etc. That possibility is always there when you have an opensource project. Just look at Xbmc and how many spin-offs have resulted from that. You can argue that it made the project worse... or it made it better.

I think the worries about fragmented it, at this point, is really premature. To date there is a small number of people working on this... I've done 2 builds. At this point, I've actually spent more time discussing the build version strategy than actually doing the builds

Eventually we'll need to solve the build number "issue", but today, we are not doing frequent enough builds for it to even be a problem. I'm manually doing what script would do... which is look at the VERSION and see if it's the same as last, if not, then RESET the BUILDNUMBER, since it's a new VERSION, otherwise, increment the BUILDNUMBER.

I think that how the versions (not the build number) get updated, today is the right way. ie, as a committer, you recognize that you've made an api change, etc, so you increment the version. Jeff reviews the changes, if he doesn't think that version requires and update then he can say so, or he can ask that the version get incremented. That's why during a build, I don't touch the VERSION but I do change the build number.

I guess maybe, Jeff can speculate as to what each of the Major, Minor, Mirco and Build numbers should mean.

This site does a good job of articulating what each level of version would mean.
http://c2.com/cgi/wiki?VersionNumber

[stuckless]

Something interesting... and not builder/version related

The stats only reflect Linux and Sage.jar downloads, but it's cool, to click on the globe and see where in the world people are downloading it

https://bintray.com/opensagetv/saget...iew#statistics

[Narflex]

It's sort of tricky now with the version numbering because we're not on the regular type of release train that we used to be. I don't know yet what event would cause a major version change at this point...same for minor versions. The micro version can probably get changed every time anything non-trivial is done to the code (for now, me updating that takes a minute, so I can try to do that, anybody else can go ahead and do it along with their commit as well). Updating the gradle scripts to use the commit count as the build numbers solves the main problem of having a distinctive build number for any version somebody could have (I'm hoping stuckless does this )

[stuckless]

This build was requested because Andy updated the STV and the STV update requires a new Jar as well.

One minor packaging note, the Sage.jar is no longer a standalone download, it is, in a Zip along with the STV, under the name SageJar-VERSION.zip

[skiingwiz]

Stuckless,

How about creating an opensagetv maven repository on bintray? I think once that exists, anything we put there can be added to jcenter. That would let us publish the sage.jar and plugin jars so that others could use them easily in their builds.

I'm not sure, but I think since you own the project, you are the only one who can create repos.

[stuckless]

Originally Posted by skiingwiz

Stuckless,

How about creating an opensagetv maven repository on bintray? I think once that exists, anything we put there can be added to jcenter. That would let us publish the sage.jar and plugin jars so that others could use them easily in their builds.

I'm not sure, but I think since you own the project, you are the only one who can create repos.

That's a good idea. I've created the Maven repo, so if you guys want to play around with it, then feel free. If you create an upload configuration for jcenter (either for sage.jar or another jar), please share it. I've been meaning to play around with this, but I only have so much time

[SageWizdom]

Originally Posted by stuckless

So, far, it's hosting the Linux deb, and tgz downloads (64 bit), and the latest Sage.jar. (Be sure to click on the Files tab for the list of files to download)

Note: the Sage.jar is no longer a standalone download, it is in a Zip along with the STV, under the name SageJar-VERSION.zip

The Linux Miniclient includes the updated mplayer, if anyone want to test it out.

Depending on the frequency of the changes to core SageTV, I'll try to push updates, weekly.

I'm working on a hopefully simple (at least thorough) Linux install guide and walkthrough for anyone who wants to try the new system. What I am not sure I understand clearly (and I didn't see in the thread). If someone installs sagetv-server_9.0.3_amd64.tar.gz, do they then also need to download SageJar-9.0.3.173.zip and overwrite the Sage.jar and the SageTV7.xml files, or is the original kept up to date?

As a followup, if the zip contains just the update that should be applied as new updates come out, is there a recommended way to merge the users SageTV7.xml file with the one in the ZIP? Does a configured system store any custom settings in the SageTV7.xml file?

I'm hoping to have a first draft of the walkthrough up tonight, but will probably run through it a few times to see if I can streamline and simplify it.

Thanks for the great downloads and the hard work!