Git Repository

[blackwind]

Those who use the installer aren't interested in such information. Plugins include an "author" metadata field which shows up in the About screen; in my mind, at least, that's more than sufficient.

[cfull1]

I agree. Anyone who is interested in it can just check the git log.

Also should the license header in every file be updated? The copyright year is 2005.

[blackwind]

Can't hurt.

[blackwind]

How are things coming along?

[cfull1]

Slow ha. Actually working on it right now. Trying to sort out the chaos between 0.3.5 and 0.3.6.
Who leaves a commit message blank anyways??

[cfull1]

Was version 0.3.7.x ever made into an installer?

EDIT: Nevermind, I remember now it was.
There is a 0.3.7 branch in the repo that doesn't get merged back....I guess it was never used?
Later (1/17/2009) the version is incremented to 0.3.7 which is different than that branch.

[cfull1]

Still here! I got about 1/4 through the plugin-install branch and realized there were commits that had nothing to do with the plugin-install feature Also, everything was moved into a plugin-install folder. Not sure why this was done, maybe an issue with svn branches. Anyways, par for the course. I press on!

[Flyingsubs]

Good job! I'd like to see more development for Eventghost. I think this is a great idea. I wish i could develop tho. It'd also be cool to be able to share what we use eventghost for and maybe some templates of things we have created in eventghost. I have dont a lot of work in home automation stuff for my room that i think is really good, but could always be improved upon.


Flyingsubs

[Pako]

Firstly I must say that I welcome your initiative and I would be happy if you contribute more to the development of the program.

I admit that I've never used GIT and I do not know what the benefits are.
Still, I have nothing against it and I agree. I would perhaps also managed to learn. However, I have some conditions:
1) First, there must be someone else (besides me) who can create new builds. I think this would be needed in any case.
2) Once such a person will be here, so he must adapt some parts of program code (associated with compilations).
The current version is currently expected to SVN, so it will not work with GIT.
3) Once this is resolved, we can move to GIT. Until then, I prefer to stick with SVN.
I do not want to interfere in a single functional computer that is set to create builds.

I believe that you understand my point.
Pako

[cfull1]

Firstly I must say that I welcome your initiative and I would be happy if you contribute more to the development of the program.

I admit that I've never used GIT and I do not know what the benefits are.
Still, I have nothing against it and I agree. I would perhaps also managed to learn.

I'm very glad to have your blessing, Pako.

GIT has really picked up speed in the past few years. I'll try to sum up the major differences.

• GIT is decentralized, meaning everyone has a copy of the entire repository.
• GIT branches are so much better. They are very lightweight, easy to switch between, and easy to merge together.
• Developers benefit by being able to make a whole bunch of changes/commits on a local branch and everyone else doesn't have to know about them until the developer is ready.
• A common github example: Someone finds a bug in your code, they can fork it (branch it), fix the bug, and create a pull request which merges the changes after you accept them. This works very well with open source projects.

Take a look at these links: 5 Fundamental differences between GIT & SVN and Why is Git better than Subversion?
Feel free to pm me with any specific questions.

1) First, there must be someone else (besides me) who can create new builds. I think this would be needed in any case.
2) Once such a person will be here, so he must adapt some parts of program code (associated with compilations).
The current version is currently expected to SVN, so it will not work with GIT.

I absolutely agree. I saw the builder code used SVN before I started migrating the repository to GIT. Converting that to GIT is next on my list after the repository is complete. I also want to fully automate the deployment process after the build is done, whether this is to sourceforge or github or where ever. That way it will be really easy for the person(s) creating the build and deploy it.


All,
Sorry it is taking so long, I'm in the middle of a move and starting a new job and things are very hectic. I hate that all this is slow going and I wish I could speed it up. Thanks for your patience.

Carson

[Ganapoes]

Fine for me as well

[zian]

I'm with Pako (I think)...
Go for it.
Git it on.

Whatever helps EG keep going.
And keeps me from getting up to change the channels.
Thanks Carson.

[cfull1]

UPDATE!

I've sorted through all the posts since about March this year! I'm not going to bother getting the last few from svn. Those can be recommitted to the git repo once it's up.

Currently most of the commits are in a develop branch (previously "trunk"). I want to create a master branch and merge several major commits to it. Right now i have about 8 releases that I've identified. I might just stick with those since I don't think I'm going to have much luck finding old downloads. Or I might deem arbitrary points where there are a lot changes.

I'd say that puts me at about 90% of the way to get the repo public. Hopefully the last 10% isn't as long as it usually is.

After that point there still will be work to be done. The release process has to be reworked for git. I've also got some ideas to make the release process easier for everyone. Good news is others can start jumping in at that point! There's a lot that needs to be tested as well....plugins and core.

Thanks again everyone for your patience!
I'll keep y'all updated,
Carson

Note to self/Pako:
I didn't include the plugin support link change, because there was a big difference in the code. Probably from bitmonster's personal branch that got merged in. Also just because I want to get this done. It will need to be rethought through and added.

[zian]

After that point there still will be work to be done. The release process has to be reworked for git. I've also got some ideas to make the release process easier for everyone. Good news is others can start jumping in at that point! There's a lot that needs to be tested as well....plugins and core.

If by testing you mean us end users (very NON programmers)...
Count me in.

[cfull1]

Finally! https://github.com/EventGhost/EventGhost is up to date with the latest changes in the svn repo!

I'm so glad to be done with this. There are so many ideas popping into my head that I want to do with EG, and felt restricted with svn.
It will be SO much easier for others to make changes now. None of this sending updated files to pako to commit. Just fork, make changes, and create a pull request!

I know I've been off and on with this, because looking through each diff is a drag and a half. Not to mention half of the work was done in virtualbox.
But I will be available as much as I can now that we are about to make this transition as a community. I know this will be better for everyone.

Moving forward!
The latest release (r1640) is available on GitHub under releases.
This is different than the svn release, so it does need to be tested.

The process for creating releases should work with GitHub. Idk about SourceForge, but creating releases with GitHub is stupid easy.
This process is still manual, and we can definitely look into GitHub's APIs to make this automated, because let's be honest, that's what we are all about here.

The version naming also needs to change. Semantic Versioning was talked about before. I think the next release, the first one with git repo, should start at 1.0.0, unless there are any objections?

Now I don't know about y'all, but I'm super pumped! I'm going to start, I can't believe I'm finally saying this, making code changes!
Let me know any comments or questions y'all have!

Carson