SageTV Community  

Go Back   SageTV Community > Information & Announcements > SageTV Downloads & Instructions

Notices

SageTV Downloads & Instructions This forum is for discussions containing Downloads and Instructions related to the Open Source version of SageTV. Please do not post questions in this forum.

Reply
 
Thread Tools Search this Thread Display Modes
  #41  
Old 10-13-2015, 12:17 PM
mwnswiss mwnswiss is offline
Sage User
 
Join Date: Feb 2007
Location: Switzerland
Posts: 54
Send a message via Skype™ to 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
__________________
Standard Intel PC with 4GB RAM Ubuntu 16.04 64bit
JVM version=1.8.0_121-b13 / SageTV V9 latest
HDHR DUAL EU with 2 DVB-C and HDHR EXPAND 4DC with 4 DVB-C
XMLTV using WebGrabPlus in Switzerland
Clients: HD200, Placeshift on OSX (limited) and Windows, Sage Android Client on ShieldTV and Tablets
Reply With Quote
  #42  
Old 10-13-2015, 12:18 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
Quote:
Originally Posted by mwnswiss View Post
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?
Reply With Quote
  #43  
Old 10-13-2015, 12:38 PM
mwnswiss mwnswiss is offline
Sage User
 
Join Date: Feb 2007
Location: Switzerland
Posts: 54
Send a message via Skype™ to 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?
__________________
Standard Intel PC with 4GB RAM Ubuntu 16.04 64bit
JVM version=1.8.0_121-b13 / SageTV V9 latest
HDHR DUAL EU with 2 DVB-C and HDHR EXPAND 4DC with 4 DVB-C
XMLTV using WebGrabPlus in Switzerland
Clients: HD200, Placeshift on OSX (limited) and Windows, Sage Android Client on ShieldTV and Tablets
Reply With Quote
  #44  
Old 10-13-2015, 12:50 PM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,297
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.
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
  #45  
Old 10-13-2015, 01:47 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
Quote:
Originally Posted by Narflex View Post
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.
Reply With Quote
  #46  
Old 10-13-2015, 03:42 PM
Monedeath Monedeath is offline
Sage Expert
 
Join Date: Sep 2009
Location: Idaho
Posts: 508
Quote:
Originally Posted by stuckless View Post
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.
Reply With Quote
  #47  
Old 10-13-2015, 07:10 PM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,953
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.
__________________
Buy Fuzzy a beer! (Fuzzy likes beer)

unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers.
Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA.
Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S
Other Clients: Mi Box in Master Bedroom, HD-200 in kids room
Reply With Quote
  #48  
Old 10-13-2015, 07:14 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
Quote:
Originally Posted by Monedeath View Post
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.
Reply With Quote
  #49  
Old 10-13-2015, 07:18 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
Quote:
Originally Posted by Fuzzy View Post
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.
Reply With Quote
  #50  
Old 10-13-2015, 07:39 PM
Monedeath Monedeath is offline
Sage Expert
 
Join Date: Sep 2009
Location: Idaho
Posts: 508
Quote:
Originally Posted by stuckless View Post
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
Quote:
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.
Reply With Quote
  #51  
Old 10-14-2015, 01:46 AM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,953
Quote:
Originally Posted by stuckless View Post
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.
__________________
Buy Fuzzy a beer! (Fuzzy likes beer)

unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers.
Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA.
Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S
Other Clients: Mi Box in Master Bedroom, HD-200 in kids room
Reply With Quote
  #52  
Old 10-14-2015, 04:52 AM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
Quote:
Originally Posted by Fuzzy View Post
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.
Reply With Quote
  #53  
Old 10-14-2015, 05:25 AM
Fuzzy's Avatar
Fuzzy Fuzzy is offline
SageTVaholic
 
Join Date: Sep 2005
Location: Jurupa Valley, CA
Posts: 9,953
Quote:
Originally Posted by stuckless View Post
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.
__________________
Buy Fuzzy a beer! (Fuzzy likes beer)

unRAID Server: i7-6700, 32GB RAM, Dual 128GB SSD cache and 13TB pool, with SageTVv9, openDCT, Logitech Media Server and Plex Media Server each in Dockers.
Sources: HRHR Prime with Charter CableCard. HDHR-US for OTA.
Primary Client: HD-300 through XBoxOne in Living Room, Samsung HLT-6189S
Other Clients: Mi Box in Master Bedroom, HD-200 in kids room
Reply With Quote
  #54  
Old 10-14-2015, 06:02 AM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
Quote:
Originally Posted by Fuzzy View Post
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
Reply With Quote
  #55  
Old 10-14-2015, 06:47 AM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
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
Reply With Quote
  #56  
Old 10-14-2015, 11:55 AM
Narflex's Avatar
Narflex Narflex is offline
Sage
 
Join Date: Feb 2003
Location: Redondo Beach, CA
Posts: 6,297
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 )
__________________
Jeffrey Kardatzke
Google
Founder of SageTV
Reply With Quote
  #57  
Old 10-14-2015, 05:01 PM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
New Build



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
Reply With Quote
  #58  
Old 10-24-2015, 10:20 PM
skiingwiz skiingwiz is offline
Sage Aficionado
 
Join Date: Jan 2005
Posts: 349
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.
Reply With Quote
  #59  
Old 10-25-2015, 07:19 AM
stuckless's Avatar
stuckless stuckless is offline
SageTVaholic
 
Join Date: Oct 2007
Location: London, Ontario, Canada
Posts: 9,430
Quote:
Originally Posted by skiingwiz View Post
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
Reply With Quote
  #60  
Old 11-25-2015, 05:10 PM
SageWizdom SageWizdom is offline
Sage Advanced User
 
Join Date: Oct 2013
Location: https://github.com/SageWizdom/SageConnect
Posts: 216
Quote:
Originally Posted by stuckless View Post


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!
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
SageTV is Open Source!!! Narflex Announcements 1 01-12-2016 10:36 AM
SageTV Open Source FAQ Opus4 SageTV Software 5 11-11-2015 02:57 PM
SageTV Open Source Narflex Announcements 0 03-09-2015 02:39 PM
Why ISN'T Sagetv open source? matterofrecord General Discussion 9 11-30-2014 10:49 AM


All times are GMT -6. The time now is 03:54 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Copyright 2003-2005 SageTV, LLC. All rights reserved.