LiveCode Forums.

Hi all,

This is just to let you all know the release-6.0.1 branch has now been merged into master. Hopefully we've resolved the majority of the build issue, so branching off master should be a little easier now!

This release contains a number of bug-fixes and full details can be found in the release notes.

Installers for the community edition can be found here:

Mac:
http://www.runrev.com/downloads/livecod ... _1-Mac.dmg
Windows:
http://www.runrev.com/downloads/livecod ... indows.exe
Linux:
http://www.runrev.com/downloads/livecod ... -Linux.x86

Warmest Regards,

Mark.

Will you open a develop branch now? It would be much better if we could branch any features off that and if there was constant integration from release branches into develop. Or will we always branch off master and leave pull requests waiting until you open release branches you want to integrate them into?

Yes, please. The current situation is a pain to work with.

Yes - I'll sort this out today - I ran out of time yesterday!

The 6.0.1 release took a little longer than I had intended, and I agree that with the initial build issues it was a bit of a pain.

In general I'd suggest that small features that don't depend on anything on the develop branch should be branched off master - this makes them more agile; larger features that are going to take a while should be branched off develop and then be kept up to date from develop until such a time they are ready for inclusion in a release.

Hopefully the only things pulled into 'release' branches will be bug-fixes, and we'll certainly try and ensure we pull them into both the release branch and develop at the same time (assuming they are relevant to both).

Okay that should be the 'develop' branch there now. I branched it off of the 6.0.0 tag and merged in release-6.0.1 - this means the 'network' graph in github is clearer. Let me know if you notice any problems.

I still don't really get why you want us to branch off master at all... shouldn't anything new branch from develop and bug fixes branch from release or more complicated ones from develop. That way our branches always are from whatever the current head is when we branch which is less likely to require manual merges... how does branching off master add agility?

Well the idea is that by having bug-fixes (wherever possible) branched off of master it makes it easy to stage them for inclusion into periodic maintenance releases as well as being merged into develop. The idea is that the maintenance cycle will be fixed (say monthly) - (say) first week spent integrating pending bug-fixes that are suitable; then (say) three-weeks in a frozen phase where we can see if there have been any regressions.

Hi, I thought 6.0.1-rc was supposed to have the revBrowser external? As per 6.0.1-gm (this), the browser sample still errors out.

CoffeeCone wrote:Hi, I thought 6.0.1-rc was supposed to have the revBrowser external? As per 6.0.1-gm (this), the browser sample still errors out.

Yeah, I posted comments to that effect on two issues (10849 & 10835) on the quality.runrev.com issue tracking site back on the 30th April. Complete silence since...

Andrew

@andrewmk, @CoffeeCone: Yes, revbrowser should have been included in the Windows build. I've posted the necessary file and where it needs to be put to the bug report http://quality.runrev.com/show_bug.cgi?id=10849. We'll fix this for the next release - sorry for the inconvenience.

runrevmark wrote:@andrewmk, @CoffeeCone: Yes, revbrowser should have been included in the Windows build. I've posted the necessary file and where it needs to be put to the bug report http://quality.runrev.com/show_bug.cgi?id=10849. We'll fix this for the next release - sorry for the inconvenience.

I would have reopened the bug report if I was able. Should I have filed a new one rather than commenting on an existing one already marked as "RESOLVED"?

Andrew

@andrewmk: Ideally you'd be able to re-open the report - however, it seems bugzilla only allows the original reporter to do this at the moment. We'll look into changing this in due course - there doesn't seem to be an obvious way to enable it at the moment so will need some digging around.

I don't think reopening bugs in a "closed" state is a good idea. Reopening "resolved" bugs is a different story.
I think the proper procedure is to open a new bug and reference the closed bug if necessary.
I haven't checked into this, but I'm reasonably sure it's possible to configure bugzilla to disallow comments on closed bugs.

And I believe the only way bugzilla allows a non-reporter to reopen a bug is for you to allow anyone to reopen a bug report, i.e., it's either just the reporter or it's anyone. Opening this up can easily get chaotic. And not in a good way.

@mwieder - I meant 'resolved - fixed'... We hadn't closed the bug at that point as it was after rc-1 the comment was made and we missed it. I agree about once bugs are actually 'closed' they should remain so.

OK - we're on the same page then.