I've added a dist target to the ant build, which creates a zip and a
tar.gz. I didn't yet try to do a source.zip and source.tar.gz - I'm
looking for advice on that one, since there will be .svn files as well
as build directories in the source tree that all should be excluded.
Does anyone have a pointer to a decent way of doing this under ant?
Karl
On Wed, Nov 10, 2010 at 6:34 AM, Karl Wright wrote:
> According to Grant, nightly builds are unnecessary for a release process.
> A reliable release ant target IS necessary, so after a short comment
> period I'm happy to put that in.
>
> We can (and should) create both a release branch AND a release tag in
> SVN. For the Wiki, I know of no branch or release technology. If
> this, too, is to be branched, the content should be folded into the
> MCF site, which is in SVN and can thus be branched/released like
> everything else.
>
> That begs a broader question. At the moment I don't know how we'd
> handle multiple site versions. Ideally, we'd want to make the release
> # be part of the site URL. But Forrest's way of building sites is
> very unitary; it's not clear we could do it that way. Probably we
> could either structure things so that each release had its own Forrest
> site, with a main Forrest site that would link to each release site,
> or we'd have just one site that we modified to keep materials from
> each release around. Thoughts?
>
> Karl
>
> On Wed, Nov 10, 2010 at 1:22 AM, Jack Krupansky
> wrote:
>> And the wiki doc is also part of the release. Does this stuff get a
>> version/release as well? Presumably we want doc for currently supported
>> releases, and the doc can vary between releases. Can we easily snapshot the
>> wiki?
>>
>> Will we have nightly builds in place? I think a 0.1 can get released without
>> a nightly build, but it would be nice to say that we also have a "rolling
>> trunk release" which is just the latest build off trunk and the latest
>> wiki/doc as well. So, some people may want the official 0.1, but others may
>> want to run straight from trunk/nightly build.
>>
>> -- Jack Krupansky
>>
>> -Original Message- From: Karl Wright
>> Sent: Tuesday, November 09, 2010 1:56 PM
>> To: connectors-dev@incubator.apache.org
>> Subject: Re: Release?
>>
>> Proposal: Release to consist of two things: tar and zip of a complete
>> source tree, and tar and zip of the modules/dist area after the build.
>> The implied way people are to work with this is:
>>
>> - to use just the distribution, untar or unzip the distribution
>> zip/tar into a work area, and either use the multiprocess version, or
>> the quickstart example.
>> - to add a connector, untar or unzip the source zip/tar into a work
>> area, and integrate your connector into the build.
>>
>> Is this acceptable for a 0.1 release?
>>
>> Karl
>>
>> On Tue, Nov 9, 2010 at 10:22 AM, Jack Krupansky
>> wrote:
>>>
>>> Oh, I wasn't intending to disparage the RSS or other connectors, just
>>> giving
>>> my own priority list of "must haves." By all means, the "well-supported"
>>> connector list should be whatever list you want to feel is appropriate and
>>> exclude only those where "we" feel that "we" would not be able to provide
>>> sufficient support and assistance online.
>>>
>>> That's great that qBase is offering access.
>>>
>>> BTW, I was just thinking that maybe we should try to keep logs of each
>>> connector type in action so that people have a reference to consult when
>>> debugging their own connector-related problems. In other words, what a
>>> successful connection session is supposed to look like. So, have a test
>>> and
>>> its "reference" log.
>>>
>>> -- Jack Krupansky
>>>
>>> -Original Message- From: Karl Wright
>>> Sent: Tuesday, November 09, 2010 9:46 AM
>>> To: connectors-dev@incubator.apache.org
>>> Subject: Re: Release?
>>>
>>> If you can claim "well supported" for the web connector, you certainly
>>> should be able to claim it for the RSS connector. You could also
>>> reasonably include the JDBC connector because it does not require a
>>> proprietary system to test.
>>>
>>> But if your definition is that tests exist for all the "well
>>> supported" ones, somebody has some work to do. I'd like to see a plan
>>> on how we get from where we are now to a more comprehensive set of
>>> tests. I've gotten qBase to agree to let me have access to their Q/A
>>> infrastructure (which used to be MetaCarta's), but that's only going
>>> to be helpful for diagnosing problems and doing development, not for
>>> automated tests that anyone can run.
>>>
>>> Karl
>>>
>>> On Tue, Nov 9, 2010 at 9:38 AM, Jack Krupansky
>>> wrote:
And one of the issues on the list should be to define the
"well-supported"
connectors for 0.5 (or whatever) as opposed to the "code is there and
thought to work, you are on your own for testing/support" connectors.
Longer
term, "we" should get most/all connectors into the well-supported
category,
bu
