releases & repository structure

[Peter Boughton]

Hey guys,

I want to do the following things:

1) Release current 1.4.5 from preview as v1.4.5b and move it to main /update site.

2) Promote latest code in Git to rc1.4.6 and publish to /update-preview site.

3) Implement the nvie/gitflow structure for the repository (i.e. sensible branches).

4) Update the repository readme file with build/commit instructions.

Indeed, I've already got a bunch of that done: I've refactored my local repo to use the nvie structure, created an rc1.4.6 branch, updated the "What's New" section for that, and started on an updated readme. (I have not yet pushed any of these changes to GitHub.)

If there are no objections to all this, and if someone gives me access/instructions for the update sites, I can see about getting the remaining parts done.

I remember there was discussion before about trying to time releases with every (other) full moon - the next of which is this coming Friday - so it'd be great to have everything ready for then.

Thoughts?

[Jim Priest]

Sounds good to me!  I'm out today but can get you access early next week if no one chimes in before that.

Jim

[Andrew Myers]

Sounds great Peter.  Good job!

--
You received this message because you are subscribed to the Google Groups "CFEclipse Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cfeclipse-de...@googlegroups.com.
To post to this group, send email to cfecli...@googlegroups.com.
Visit this group at http://groups.google.com/group/cfeclipse-dev.
For more options, visit https://groups.google.com/groups/opt_out.

[denstar]

On 02/08/2014 06:59 AM, Peter Boughton wrote:
...

> I remember there was discussion before about trying to time releases with
> every (other) full moon - the next of which is this coming Friday - so it'd
> be great to have everything ready for then.

Sounds like a plan, man!

As for the gitflow, that sounds good too. We started off using it, when
we first moved to git, but I think it was just too much change at once.
Now that more folks (including myself) are more familiar with git and
gitflow, we should give it a go again.

To generate the update sites and standalone version, theoretically we'd
just merge the release into master and let Buckminster build from that,
I think.

:DeN

--
I do not fear computers. I fear the lack of them. - Isaac Asimov

[Andrew Myers]

I'm not familiar with Buckminster Denny - but it looks like some kind of
Eclipse build system?

One of my sort of "fuzzy" ideas that I had moving forward was some kind
of automated build (nightly or weekly or something). I was thinking
perhaps something like Cloudbees@DEV might be suitable. Or would this
Buckminster take care of that?

Correct me if I'm wrong, but another thing I identified that *I think*
we need to do in order to move the automation forward was make it more
modular so that the latest versions of cfml.parsing, cfml.dictionary and
cfml.formatting projects get re-built for each milestone build.

Does that sound fair?

Andy

[Peter Boughton]

Cool. I've pushed up the branching changes I did (https://github.com/boughtonp/cfeclipse) - hopefully it makes sense.

Should the update sites be split out into a separate repo?

Otherwise, especially if we have /update-dev with nightly/weekly builds it'd be polluting the main master with those commits? Or am I misunderstanding what you mean with Buckminster?

[denstar]

Yep, Buckminster is a build system. It does a lot more than just
eclipse stuff, and was better than the maven deal (Tycho IIRC-- I tried
them both).

Just to be clear about how badly I've dropped the ball: We've had
automated builds for over a year now, I think. I'm pretty sure that you
can even just use a magic command line with cfeclipse-releng and have it
set up a CI server & build job (uses jenkins) for you.

Hilarious as that is, the same goes for most of the projects I work on
(even plain old CFML projects), including cfml.parsing and cfml.dictionary.

Theoretically, we commit to cfml.parsing, it runs the unit tests (the
only unit tests we have so far, though I'll chime in on that ticket
about Eclipse UI/etc. testing, as I have some experience there with the
egit codebase), and if the tests pass, a new artifact gets added to the
artifact repo, and once there's a good artifact, we take that version
number and update the requirement for CFE, and thus semi-magically we've
upgraded the parser.

The idea is that the parser is the thing we need to test the most, and
potentially upgrade the most, so as it is, you can upgrade the parser
without having to upgrade all of CFE. We should def make sure the
latest and greatest is out when a milestone is, but I just wanted to
throw that bit out there, module-wise.

Feel free to ask about the stuff that's not clear, and I am serious
about putting docs about all this crap out. For realz. FTW this time!

:Denny

--
Part of the inhumanity of the computer is that, once it is competently
programmed and working smoothly, it is completely honest.
Isaac Asimov

[Jesse Shaffer]

Just curious - I know there have been several updates to the project over the last year - including some modifications I submitted, but the latest version available from any of the update sites is from 2012 (on update-dev).  What is the current update site to get the most recent updates?

[Peter Boughton]

My understanding was that those updates were in Git but not on an update site.

That's where my suggestion to move the 2012 release from /update-preview to /update, and then deploy those git changes (as rc1.4.6) to /update-preview came from. (There isn't actually a current update-dev URL is there?)

Unfortunately I was completely braindead over the weekend so haven't yet looked into any of the stuff Denny mentioned - am hoping to have a free evening tomorrow to investigate that.

[Jesse Shaffer]

Yes, there are 3 update sites - update, update-preview, and update-dev.

I saw the stuff about Buckminster and automated builds, I assumed that the automated builds have to be generating some sort of artifacts, to include the stuff for the update site.  I'm not very well versed in the myriad of java build processes, beyond Ant+Ivy and Jenkins. Which also makes me wonder, how does Buckminster differ from a regular Jenkins/Hudson install?

--
You received this message because you are subscribed to a topic in the Google Groups "CFEclipse Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cfeclipse-dev/TkHvecwYBF4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cfeclipse-de...@googlegroups.com.