@Caleb, I've merged the first but got a question about the second: if I want to update the readme, what's the best way to proceed? switch to your release branch and do it there and then merge, or just merge and then add another commit on master?

I'm not too clear about what happens if I switch to your branch... I don't think I then have to push back to github? I can just sync master afterwards?

If the changes in question are really release related you could branch from my rel133 branch and continue adding commits where I left off. That could then be merged yourself or pushed to GH and open a PR back to mine for review. If they are not release items but just general devel work that be in before starting the release branch push them to your devel and rebase the release branch.

In the case of readme stuff I would treat it like a hotfix and do the changes straight to master, maybe even before you hit merge on the release branch.

@Caleb Before? that seems weird.

@Benjol Depends on what the changes are I guess. If they have anything specific to 1.3.3 then after makes sense (or add to the release branch first). I was thinking there were readme things that just should have already been fixed unrelated to a new release to doing them as a hotfix from-to master made sense and having the 1.3.3 merge be the last thing in master made sense.

But it's really more about what makes sense for the changes you have in mind.

@Caleb, ok, I understand better. It was adding the 'release comment', which was why I was confused

bite the bullet time :)

If you want I'll push my 1.3.3 branch to your repo and you can fiddle with it and merge from there.

Nah, it's ok. From what you said, I can just switch to it locally, do my change and then merge to master and push that

@Caleb, is Oliver's quick insert ready for public consumption? I have a reference to his gist in the README which really needs updating or removing (to avoid even more confusion).

@Benjol No it really isn't. I would remove the note about it for now.

But I could leave the reference to Derek's chrome extension?

It's nice stuff but we've both played around with various versions of it and neither of us polished it up for release.

@Benjol I don't know, he hasn't run with the ball yet so it's a little awkward, but I guess it doesn't hurt.

ok, I'll leave that in

Fair enough.

@Caleb, ok, done and merged to master (locally). What should I do with devel, merge master in, or rebase onto master (I would normally rebase, but I'm used to working alone)

@Benjol No don't rebase in this case, that will screw our feature branches up. Merge will also screw up the included files, so really the thing to do is cherry pick the readme fix back to devel.

ok, I'll try and do that :)

That's an awkward one because release notes don't really belong in the repo anyway, they should be attached to tags or in a separate file that stays with the release branch only and doen't come back to devel.

@Caleb, a bit like what you did for the build files in devel?

@Benjol Yup.

@Caleb The problem is our release branches are currently 'made from' devel, so they don't really have a life of their own

I could just not bother to cherry pick, but then we'd run the risk of losing that change, I guess

@Benjol That is as it should be, but there is no reason they couldn't be branched much earlier and the release "set up", then periodically merge devel into the release branch until it's ready to go. That way release specific docs etc could be prepped any time.

@Benjol Correct.

@Caleb, so we should branch the release from master? (I can't see if that's what you did now, because the branch network looks like spaghetti here :))

@Benjol No, it should initially branch from devel, but it doesn't really matter when.

@Caleb, but wouldn't that mean we'd have to manually put the README back in each time? (if devel doesn't contain README?)

And there are a standard set of changes it should always include sometime before merging to master. Version bump and adding prebuilt userscripts being the two obvious ones.

@Benjol The README should be worked on in devel and/or feature branches all along. (and NOT include release notes at all)

@Caleb aaaah (penny drops)

ok. I'll do something about that later :)

@Benjol Ya no rush, I'm describing an ideal world here well aware that it never quite pans out that way :)

@Caleb, well this is a good pint-sized project to be practising my git-fu on

@Caleb, ok all synched. Next step gist, I guess?

I just hope nobody went and installed V1.3.1 manually :(

@Benjol Me too actually, and I've been wanting to understand some userscript stuff better to try my hand at another project so I've been picking up bits from you and @OliverSalzburg on that side of things.

@Benjol It's okay if they did, they will get upgraded too.

@Caleb, wow, good. You should ping @balpha some time :) I told him he was evil way back when...

If they have the OLD 1.3.1 gist, they are pointed at the file it the root of the GH master still for updates and I updated that to be able to respond to them properly and get them on track too.

That really was a spaghetti monster.

@Benjol I did. And he is.

ok gist done.

@Benjol No kidding. I'm not sure you saw my simulation branches trying to get the updater to handle the 4 separate cases it could have been stuck on but there are like 30 commits in my repo with -m debug before I figured out what to actually change and add to a clean branch. Testing it was a real bugbear when it behaved differently of different starting versions and URLs. I'm still crossing my fingers that it works.

I saw it when it was at 6/7 commits...

To be honest, I'm still not sure why SE doesn't adopt it. I know (or I think I recall) that even Shog9 uses it.

@Benjol Ya, and they sometimes mention it in the moderator room when training new mods. I think there is a justafiable fear of encouraging users to go this way without thinking about their comments.

As I recall they did half-implement it for review queues at some point.

@Caleb, yeah, I guess so. Oh well... On another topic: I guess fighting with the update script has given you a clear idea of how you don't want to do auto-updating comment sets? :)

@Benjol Yes!

@Caleb, do you think 'comment set' is a good name for this 'thing'?

@Benjol Yes, for lack of a better idea.

@Caleb, ok, that's a good place to start. The proposed functionality still seems a bit hairy to me.

@Benjol If nothing else it is something to let brew in a feature branch somewhere for a good long time before pushing out to anyone! I have an idea it can be made to play nice but it isn't going to be a one-commit-and-were-done change.

@Caleb, I think I may be having line-ending problems...

Can you check on your end, and then I'll see how to fix git (if it's git) here for that.

@Caleb, yup, autocrlf was set to false

The good news is that we should be able to use the auto-update code to let people install from a feature branch and still get updates and optionally eventually update them back to master if it their feature merges.

@Caleb, wow.

@Benjol Speaking of I just set that up in a parallel universe. Installing from this location should auto update to this branch as a longer term alternate master release and a corresponding devel branch is ready for hackery.

@Caleb, did you resolve the .min problem? I thought you had, but I just built in devel and it seems to point to the normal script?

I guess ultimately it doesn't make much difference, as the script doesn't auto-install.

@Benjol No the min version isn't working right. It breaks the auto-updater so I have it pointed at the other one right now. We can migrate people if we get it working right. I wouldn't even mention it in the docs for the moment.

@Caleb, oops. OK. anyway. thanks for all of that. It'll be interesting to see if we get any feedback!

@Benjol github.com/Benjol/SE-AutoReviewComments/issues/24

The closure compiler is apparently pretty aggressive and factors out evil code.

@Caleb, ah, yes. Nasty

@Benjol Leaving ourselves cookie trails to be found and consumed by past or future iterations of ourselves was not something it takes into account by default and I didn't have time to figure out how to make it behave on top of the other updater chaos.

one thing at a time

I've deleted the minified version from the github release

@Benjol I just converted the release notes to annotated tags. See here. Do you mind if I push those tags to your repo? I don't thing Github can do that with a PR.

Actually hang on I bet I can timestamp those properly first.

now all we need to do is write a clever bash script to drop that into README.md, or RELEASE.md?

@Benjol All tags back dated to mach their commits. Now can I push tags?

@Caleb, yup, looks good to me. How did you back date them?

@Benjol That would be easy enough to cook up :)

@Benjol for tag in $(git tag); do git checkout $tag ; GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag $tag $tag -f -a; done

You asked.

@Caleb. What's the relationship between the tags you just did and the 'releases' that I created manually from github?

@Benjol Not sure. I think it added the tag the same as I did manually and then attached a bunch of meta information to it that isn't part of the repo itself.

Interestingly the meta information about the release survived be deleting and writting a new tag with the same name with the release note data in an annotation.

@Caleb, yes, that's why I asked :)

But apparently it doesn't show your annotation in the web interface

@Benjol They must be nicely linked to tag name rather than some internal reference. Github does some things right!

It does but not in the same place. See the little expander dots here vs the last two having a "release notes" link.

strange, if I do a git tag -n5 locally, it only shows the commit message for the last two.

@Benjol You need to pull tags then.

git fetch --tags

strange, because a sync pulled in the others

(from smartgit)

but yes, it worked

@Caleb, some chat housekeeping ideas: edit the description to point to stackapps and/or github

Maybe have 'release' message for each release which we can star.

Maybe also for each bug fix.

Released V1.3.3

^ like that ^ :)

@Caleb, ok, I get the hint :)

Oh, you did it already.

@Benjol That was accidental! copy\pasted url from the wrong tab.

@Caleb, no I thought that you adding me as owner meant I should/could edit the description myself

@Benjol Sure, somebody just has to say something in here, but hopefully most people will get the message anyway :)

ok. Thank you. Is there a way you can move this out of SR and on to just SE, or is there no notion of a pure-SE chat room?

@Benjol That too. Undo is a chat mod so he doesn't need any special listing. So is Oliver for that matter, and you can now do basic room admin here.

ok

@Benjol There is actually, and I think I can do that...

@Caleb, ok, thanks. gotta go. Seeya later. ANd thanks again.

@Benjol I can't find a way to change that. I'll try to catch an employee sometime and have 'em fix that.

I took the liberty of creating a milestone (1.3.4) on GitHub. Just so we can keep track of issues to take care of before the next release cc @Benjol @Caleb

@Caleb Nice work on the wiki!

@Caleb I also noticed there are a few URLs in the autoupdater.js which could possible be replaced with @ant-homepage@. In case you want to do that

@OliverSalzburg Might as well. And an @ant-stackapps@ one too.

or @ant-github-project@ or whichever way those go. One is for the readme on github the other for the app page.

The readme one will eventually need to point to whatever we use for release notes, but that hasn't quite settled down. See ^^^ re tags.

Seems like it's not possible to simply preserve single variable names with closure compiler. Would something like this be a possible approach?

var updaterOptions = {
  "VERSION" : '@ant-version@',
  "URL" : "@ant-raw-source-root@@ant-userscript-filename@"
}

Not easily. It would take two releases and doubling up code for both the old and new way for the interim release.

Heh. How about this then?

this["VERSION"] = '@ant-version@';
this["URL"] = "@ant-raw-source-root@@ant-userscript-filename@";

@JourneymanGeek What are you doing lurking in here btw? :D

No idea

Heh