Initial Release

[AdmiringWorm]

Initial realse of the transifex cake addin which adds support for status, push and pull.

[gep13]

👍

[gep13]

@AdmiringWorm as a side note, you might want to make the develop branch the default branch.

[AdmiringWorm]

@gep13 not with my work flow, if I set the develop branch as the default issues would close when a commit/PR is merged to the develop branch.
IMO issues should stay open until they have been provided in the a stable build.

[gep13]

Interesting... hadn't thought of it that way.

The main reason that I do it is so that PR's from external contributors come into the correct branch. 9 times out of 10, they use the default branch, without thinking.

[AdmiringWorm]

The main reason that I do it is so that PR's from external contributors come into the correct branch. 9 times out of 10, they use the default branch, without thinking.

While that is certainly a problem, I've never had that many PR's on my projects so it's never been I problem for me. Only once that I can remember, in that case I just re-targeted the PR to the develop branch, and asked the submitter to rebase/merge it towards the develop branch.

[gep13]

We (Cake) have had a few issues with it in the past, but I totally understand your point of view as well. Going to have to mull this one over a bit 😄

[AdmiringWorm]

👍
I'll probably set the develop branch as default if it ever becomes a problem in the future.
BTW, do you know if there is possible for the gitreleasemanager to create a changelog based on issues that are pending closure? (don't know if the github api supports this or not).

/cc @gep13

[gep13]

GitReleaseManager is based off of the fact that issues have been:

• Labeled with one, and only one, of the configured labels
• Is assigned to a milestone
• The issue is closed

That is not to say that these things won't change in the future, but that is how it currently works.

[AdmiringWorm]

yeah, I thought that was the how it worked. Just wanted to make sure, just in case I was missing something.

[gep13]

Happy to take any input on how it can be done different. That project is somewhat neglected. Need to get back to it at some point.

[AdmiringWorm]

Unfortunately I don't know if it is even possible to get a pending closure state (couldn't find any in the api documents).

I'll probably open a issue on GitReleaseManager sometime in the future detailing my views on some changes.

[gep13]

@AdmiringWorm said...
Unfortunately I don't know if it is even possible to get a pending closure state (couldn't find any in the api documents).

Likely not. Would likely need to be an additional label to provide an indication of current state. i.e Done

@AdmiringWorm said...
I'll probably open a issue on GitReleaseManager sometime in the future detailing my views on some changes.

Sounds good to me.

[gep13]

@AdmiringWorm great work on getting this released 👍

[AdmiringWorm]

@gep13 thanks, had to skip a few corners when trying to build it on osx and linux though. (tooling issues)

[gep13]

@AdmiringWorm baby steps 😄

So, you doing a PR to the ChocolateyGUI repo next? 😛

[AdmiringWorm]

So, you doing a PR to the ChocolateyGUI repo next? 😛

while I could do that, there would still be some steps that needs to be done before I can.
Most notably the creation of the project on transifex.

There probably should also be some kind of discussion on whether the translated sources should be checked in or not and if everything should be automated on appveyor or not.

[AdmiringWorm]

in the meantime I've updated the Hello Transifex demo project.