Version 26 about netspeed HOT 16 CLOSED

Bump. Can we get any input here, @hedayaty ? We'd like to package your handy extension for the Fedora repos.

from netspeed.

i attached this patch here again
gnome-version.patch.txt

--- metadata.json.orig	2016-09-24 20:55:00.271703580 +0200
+++ metadata.json	2016-09-24 20:55:48.718786144 +0200
@@ -3,8 +3,8 @@
   "description": "Displays Internet Speed",
   "name": "NetSpeed",
   "original-author": "[email protected]",
-  "shell-version": [ "3.10" , "3.12", "3.14", "3.16", "3.18" ],
+  "shell-version": [ "3.10", "3.12", "3.14", "3.16", "3.18", "3.20", "3.22" ],
   "url": "https://github.com/hedayaty/NetSpeed",
   "uuid": "[email protected]",
-  "version": 25
+  "version": 26
 }
--- stylesheet.css.orig	2016-09-24 20:56:05.080804000 +0200
+++ stylesheet.css	2016-09-24 20:57:35.849912322 +0200
@@ -1,11 +1,12 @@
 /* Example stylesheet */
 .ns-label {
 	text-align: right;
+	padding-top : 3px;
 }
 
 .ns-unit-label {
 	font-size: 65%;
-	padding: 5px 2px 0px 0px;
+	padding-top : 8px;
 }
 
 .ns-menuitem {

from netspeed.

Or maybe this thread should be a more general question of what the intended version numbering scheme is supposed to be, and what the current version release is.

The biggest source of confusion on this point may be the CHANGELOG, which shows the latest version number as 3.16. I have a feeling that that's intended to be the compatible GNOME Shell version? But that would not be how CHANGELOGs are normally formatted, and it contradicts the version number in metadata.json.

from netspeed.

Sorry, I see a surge of comment on issues, I am on vocation for a little bit longer.
Just something short, the versions are not meant to match the versions of gnome.
They just reflect my changes. Unfortunately, there might be gaps between github and extensions :(

from netspeed.

Sorry, I am back with the new version of Fedora.
Looking around for what I have been doing with the extension.

from netspeed.

I do not know how I have lost those changes on the repo! Maybe I was using a different computer and did not push the changes to github. Ironically, half the changes are already in my repo

Anyway, thanks for sending the patch.

from netspeed.

@terrycloth Adding to Fedora seems like a nice idea. I originally was half way there. When, gnome extension site started I held the Fedora one.

I might be still listed as a package maintainer for Fedora. I you can help me, I would be glad to add this to Fedora

from netspeed.

@ hedayaty I am also a package maintainer for Fedora and i have already created a new package request on bugzillla.

from netspeed.

I just noticed that commit 0b769d5 from a couple days ago bumped the version number to 27. To be clear, does that commit mark the version 27 release, or is there going to be a git tag coming up? Thanks.

from netspeed.

Sorry, but one more time: @hedayaty Are you planning on doing a git tag on the version 27 release, or is commit 0b769d5 the commit we should use to build our Fedora package?

from netspeed.

So sorry, about my late follow ups.

• Now both gnome and github must be in sync.
• The locale patches are applied + few minor fixes to po files.

from netspeed.

Anything else we need to do?
I do not mind adding the spec file to repo (not sure with commit-id)

I saw the last comment There are a couple important issues still open upstream?
So was he referring to github being out of sync?

from netspeed.

BTW, thanks @terrycloth @martinkg for following up and help

from netspeed.

Developers who track their projects in git will typically use a git tag to mark a new official release. This way, people who build the software from source code know to use code at those points in the revision history. Code based on git commits from between different tags are not part of the official release, and may not work properly, because they contain incomplete work.

@hedayaty you occasionally edit the "version" string in metadata.json, but there have never been any git tags. So it's hard to tell which commits are actually part of the official release. Does commit 06dbae2 mark the point in the revision history for version 28? Seems likely, but this requires us looking through the commit history and guessing. If you used git tags, it would be less ambiguous, and it would be easier to periodically check if there was a new release out yet.

from netspeed.

@terrycloth I see.
I have setup Jenkins to do this at work before.
Doing it manually is not really a chore. Let's me start doing it.

from netspeed.

can you please update the metadata.json for newer gnome version 3.28 and 3.30 ?
"shell-version": [ "3.10" , "3.12", "3.14", "3.16", "3.18", "3.20", "3.22", "3.24", "3.26", "3.28", "3.30" ],

from netspeed.