Preparing for release 1.1

[Rich Hickey]

We are at a good point to release a version 1.1. This will include
everything currently in the master branch and nothing from the new
branch. I've gone through all of the existing patches and the ones due
to go into 1.1 have been applied.

We will need some collective effort to get the release out. Stuart
Sierra has volunteered to coordinate (thanks Stuart!).

Here are some things we need to get together:

- lists of features and fixes since 1.0
- docs for bigger features that won't be covered well in doc strings
(e.g. chunks, transients, letfn)
- any packaging issues (we've had complaints about the .zip littering
the expansion dir)
- new API docs from Tom Faulhaber's process
(these are in place - thanks Tom!, and links to the new docs are
in place -thanks Chouser!)
- maven stuff (while we build Clojure with Ant, there are always
artifacts, release numbering issues for Maven)
- a plan for release candidates (we should get one out soon)
- bundled contrib release (a thread has been started by Stuart)

And finally - what's not on this list? Any volunteers to help?

Thanks for your help and input,

Rich

[Stuart Sierra]

On Dec 7, 7:10 am, Rich Hickey <richhic...@gmail.com> wrote:
>  - bundled contrib release (a thread has been started by Stuart)

I thought you wanted to postpone that discussion until after 1.1. Did
you change your mind?

-SS

[Sean Devlin]

I'd love to help out with this.  I'll help review documentation where I can.

Also, a request.  Could you rely a bit more on the mailing list/assembla and not IRC for this stage of a release?  It will make it easier to keep track of what is done, and filter out the noise.  That, and some of us has trouble getting to IRC during the day.

Looking forward to 1.1,
Sean

--

You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To post to this group, send email to cloju...@googlegroups.com.
To unsubscribe from this group, send email to clojure-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/clojure-dev?hl=en.

[Tom Faulhaber]

One thing we should probably do as part of this process is to remove the deprecated ^s from contrib. No point in having folks get deprecation warnings as soon as they update. I did a grep over the weekend and it didn't look too bad.

I'll create a ticket for this in contrib.

Anything else we should consider along these lines?

Tom

[Laurent PETIT]

Stuart, I guess Rich is talking about the fact of releasing a version of contrib simultaneously (just as contrib-1.0-compat for clojure 1.0), not thinking about integrating contrib stuff into clojure stuff.

My 0.02€,

--
Laurent

2009/12/7 Stuart Sierra <the.stua...@gmail.com>

[Phil Hagelberg]

Rich Hickey <richh...@gmail.com> writes:

> - maven stuff (while we build Clojure with Ant, there are always
> artifacts, release numbering issues for Maven)

This is particularly a problem with Contrib. Currently it's not possible
to use Clojure 1.0 and Contrib together in a project that uses an
automated dependency mechanism because the 1.0-compatible branch of
contrib has the same version number as the master branch.

-Phil

[Tom Faulhaber]

Patches welcome :-)
 

[Phil Hagelberg]

Well the question remains what the version number should be. Should
contrib's version number match Clojure's? So master would be changed to
1.1, etc? Or should we just change contrib's 1.0-compatible branch to
something like "1.0-compatible-SNAPSHOT"? Note that the latter is
totally safe since people on the 1.0-compatible branch can't rely on the
version number anyway. I'll do a ticket/patch for this if it's desired.

-Phil

[Meikel Brandmeyer]

Hi,

Is it also worthwhile to think about a more modular build of contrib? I'd don't like that a 3.5MB jar is included as a dependency just because I use 5k (eg. def) of it. I maintained such a build with my Ivy branch, but it is a little out of sync. It basically created for each module a dedicated ivy.xml etc. and did the build. Maybe this could be adapted to maven as well?

Sincerely
Meikel

[Meikel Brandmeyer]

Hi,

Am 07.12.2009 um 22:11 schrieb Meikel Brandmeyer:

> Is it also worthwhile to think about a more modular build of contrib? I'd don't like that a 3.5MB jar is included as a dependency just because I use 5k (eg. def) of it. I maintained such a build with my Ivy branch, but it is a little out of sync. It basically created for each module a dedicated ivy.xml etc. and did the build. Maybe this could be adapted to maven as well?

Just realising: if at all, this is not a topic for 1.1 of course....

Sincerely
Meikel

[Chas Emerick]

Yeah, probably not.

This is part of what I was driving at last week w.r.t. having each lib
in contrib break out on its own. IIUC, it'd be pretty easy to do--
just make each lib in contrib its own maven module, which is deployed
separately, and which people would be able to depend on separately
(modulo dependencies between contrib modules themselves). That'd
require maven to supercede ant though, which I presume isn't an option
without a blessing from Rich.

- Chas

[Meikel Brandmeyer]

Hi,

Am 07.12.2009 um 22:22 schrieb Chas Emerick:

> This is part of what I was driving at last week w.r.t. having each lib
> in contrib break out on its own. IIUC, it'd be pretty easy to do--
> just make each lib in contrib its own maven module, which is deployed
> separately, and which people would be able to depend on separately
> (modulo dependencies between contrib modules themselves). That'd
> require maven to supercede ant though, which I presume isn't an option
> without a blessing from Rich.

Well, I also just use ant (modulo Ivy for the dependency handling). I generate the ivy.xmls from a central description file. Similarly a maven pom could automatically be generated. Building the different artifacts from one build.xml could be possible. Then nothing is needed from maven....

Sincerely
Meikel

[Chas Emerick]

*anything* is possible from ant, of course. I get the sense that
people are coalescing around maven (and derivations thereof) for
clojure-related build tools, FWIW. *shrug*

We're far afield of the topic, though, so this can get picked up
another time and place.

- Chas