search

slash2009 / XWMM

XBMC Web Media Manager
Other
56 stars 20 forks source link

A clean break - Rewriting XWMM #53

Closed ghost closed 10 years ago

ghost commented 10 years ago

As suggested by @uNiversaI, this is a new issue to continue the discussion started on #44 about rewriting XWMM.

un1versal commented 10 years ago

Yes, thank you for opening it up.

I guess we can start outlining best practices and decide on what libraries are best to rewrite this as well as general todo lists etc.

Todo

Preliminary rewrite requirements (just what pops to mind) for thread start.

\ the list above is incomplete please add/remove items as you see fit.

@slash2009 @fyfe @criticalfiction @MokuJinJin and @nwtn @zernable Does this sound sane to start with? Thoughts everyone :-:

ghost commented 10 years ago

@uNiversaI your list covers it all I think. A couple of comments:

The JSON RPC API doesn't support:

The old HTTP API supported some of the above but it's deprecated and will be remove (after Gotham I think).

Why are we running two seperate branches for Frodo and Gotham? At the moment there isn't anything used in XWMM that doesn't work on both versions of XBMC. The reason I ask is I've just noticed that both branches are in different states beyond version number difference. It's nothing major but there's got to be a better way to manage this.

Until there's a feature we need in Gotham that isn't available in Frodo I think we should remove the two branches. If we use Grunt (or something similar) as a build tool we can automate generating addon.xml (the only file that needs to be different) when creating a release.

House cleaning, can we bin the Dharma and Eden branches as they aren't supported anymore?

ghost commented 10 years ago

Also removing the Gotham/Frodo/Dharma/Eden branches would make it clearer that all work should be done against master.

un1versal commented 10 years ago

The state difference is probably my fault, My git-foo is still on learning curb.

Let me try to explain how I see it.

You will always need a current stable (in this case Frodo) and development branch (master), then needs to be branched into its own branch to match xbmc sooner or later afaik (pre-Gotham though I just called it Gotham). Thats how Git works....

Why are we running two separate branches for Frodo and Gotham?

Simply, because addon dependencies are not the same for Frodo and Gotham, One size does not fit all, unfortunately.

idk how to explain it better and maybe is more complicated than needs to be, but its better than nothing at all or until things get worked out and defined.

I roped myself into this,

because There was no Frodo version and ppl responsible for developing that dont care or want to use GIT.

Until there's a feature we need in Gotham that isn't available in Frodo I think we should remove the two branches. If we use Grunt (or something similar) as a build tool we can automate generating addon.xml (the only file that needs to be different) when creating a release.

ATM no one is looking at changelogs and version changes and addon dependencies releases etc. Im doing that in background seamlessly, after it has been merged and cherry picked etc I squash those changes into the cherrypick so its cleaner commit history, thats how git is suppose to go??

It's easier for me to maintain git like this. Do I hate doing it? Sure you bet! Would I rather not do it? It goes without saying :)

If Grunt can do all of that it so much the better. If it can tag and make releases and knows where and how to appy certain fixes ### even better ###, you dont need me at all then... That would be fine with me also.

I tried to best of my ability to mirror what xbmc does, because we are dependant on what xbmc needs :)

Grunt sounds great,

It would sound better if it was easy to learn, Im not a developer, just a janitor :)

House cleaning, can we bin the Dharma and Eden branches as they aren't supported anymore?`

XBMC will branch out to Gotham when they go beta, in XWMM its happen sooner (because I dont use stable XBMC) its all.

I dont mind removing old stuff,

But for historical reasons (same as XBMC) there's no harm in keeping it either. XBMC keeps it, but the beauty of forks is they dont need to keep it old braches.

The old HTTP API supported some of the above but it's deprecated and will be remove (after Gotham I think).

You can be rip now, it doesnt do anything imo as is since xbmc uses jsonrpc so idk whats does that job afaik

@slash2009 and other please comment.

un1versal commented 10 years ago

With that said if grunt can do my current job, I can dedicate tat time to developing graphics for XWMM, which is what I rather do tbh)

ghost commented 10 years ago

I'm used to using git a little different.

As far as version numbers go can I suggest this going forward:

The git portion (branching, tagging, etc.) of this can be automated with Grunt and I might even be able to automate the creation of GitHub releases.

un1versal commented 10 years ago

{major} doesn't have to follow specifically xbmc but doesn't matter either way. Version is the lest concerning subject, so if everyone likes that we keep it I quite like it, simple.

ghost commented 10 years ago

@uNiversaI I think I forgot to engage my brain last night, looking at the version numbers now I see you already do what I proposed you just didn't use the same major version number as XBMC.

I think I might have work out a couple of ways to reduce/remove the extra admin work you're having to do at the moment. I'll post more when I've tested something that works. I still think I can come up with a way that means we don't have to maintain multiple branches for each XBMC version.

What are you changes are you making at the moment between XBMC versions for each release?

With regards to the change log it's another one that can be automated. As long as merges and tags are done correctly something like: `

On master

git checkout -b v4.0.1 echo 'Version 4.0.1' >> changelog.new.txt git log --format="tformat: - %an: %s (%h)" v4.0.0..HEAD >> changelog.new.txt cat changelog.txt >> changelog.new.txt

Check it all looks good

mv changelog.new.txt changelog.txt git add changelog.txt git commit -m 'Release version 4.0.1' git tag v4.0.1 `

Output

Also for anyone interested I've started to make some useful notes for working with XBMC on my GitHub wiki.

un1versal commented 10 years ago

Changelog wise that's cleaver though not any easier from what Im doing atm re the changelogs. As Im not doing command line only git stuff. :)

Thank for the step by step in any case I'll try it out.

Version wise, current files that need editing are

in addition also do

Tagging/releases

via Firefox

All of the above except the cherry picks and squashes (the only things I do over command line.

ghost commented 10 years ago

One of the things on my to do list is to try and automate tasks like updating change logs and creating releases. If we end up Grunt I should be able to automate it so all you have to do is bump type one command along the lines of grunt create-release v4.0.1 and it'll do everything I had in my last post.

un1versal commented 10 years ago

That sounds great, in theory, I dont have any problem with that whatsoever. and while everyone knows how to use whatever its decide on or willing to learn, thats a whole other ball game.

For me, I rather see XWMM get the attention it needs in some consistent manner, which is what made me join the efforts mainly as it was being a bit neglegted for real live reason I presume, and because I could help with gfx design. I would like to see something sharper and cleaner and modern going, while at same time being functional and doing what its suppose to and extend beyond that within reasonable parameters.

If you see #52 and see if you can make it today, I will set time aside to meet and talk with you on IRC.