Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]

2007-01-15 Thread Gregg Leichtman
I guess the thing that is most confusing to me is that on the project
summary page and on the dependencies page:

http://shale.apache.org/shale-tiles/project-summary.html

http://shale.apache.org/shale-tiles/dependencies.html

Shale is listed at version 1.1.0, but it appears that the dev group is
getting ready to release version 1.0.4. I would have thought that the
currently released and posted version on these web pages would be 1.0.3.
Is this currently posted version number correct and if so why?

I have not yet moved this discussion to the user forum, since I believe
that this topic, possibly erroneously, is still pertinent to keeping
things in synch for the next release that the dev group appears to be
planning.

 -= Gregg =-

Rahul Akolkar wrote:
 On 1/5/07, Gregg Leichtman [EMAIL PROTECTED] wrote:
  Additionally, note that the framework distribution (nightlies or
  release) contains all dependency jars in the lib folder
 Ok, that is _very_ useful (thanks, I had not noticed this and had been
 going out on my own for the past few months to try and match components
 up with Shale nightlies with various levels of success); however, when I
 go to the Tiles core download site at:

 http://people.apache.org/builds/struts/nightlies/tiles/

 I find:

 snip-list/

 None of the versioning above matches the versioning of the file
 tiles-core-2.0-r468346-SNAPSHOT.jar provided in the framework, so how
 can I correlate the two? Continue reading.

 snap/

 Its in the snapshot repository (long, possible fragmented URL) that is
 used by the build:

 http://people.apache.org/repo/m2-snapshot-repository/org/apache/struts/tiles/tiles-core/



  Its also available on the website, the dependency page for shale-tiles
  is here:
 
  http://shale.apache.org/shale-tiles/dependencies.html
 This is good also; however, I can't find any place on this page where it
 states which version of Shale these dependencies go to. I assume that
 since 1.0.3 is the currently released version of Shale, these
 dependencies apply to it, but that doesn't seem to be stated. If this is
 true, then I assume that tiles-core-2.0-r468346-SNAPSHOT.jar applies to
 Shale 1.0.3. Correct? If this is correct, maybe the dependencies page
 can have a blurb in it to state which version of Shale the dependencies
 apply to. Since the page is generated by Maven, maybe Maven makes this
 too hard to do.

 snip/

 That version applies to (a probably soon to be out) Shale 1.0.4 or a
 recent nightly. For Shale 1.0.3, it wasn't pinned down to a specific
 svn revision (and your best bet is, again, to pick up the jar that
 would have come in the lib/ directory of the 1.0.3 framework distro).

 Your point about trying to correlate this information (especially for
 someone not used to Maven and its sites) is however well taken.


  (similarly for other modules -- for each module, the 'Project
  Documentation' section in the left side navbar has this, and other,
  information).
 I don't see anything relevant under the Project Documentation section.
 I do see sub-projects under Sub-Project Documentation, but these don't
 appear to supply versioning information. For example, the link
 http://shale.apache.org/shale-tiles/index.html for tiles.
 snip/

 For example, the project summary has the version number of the
 artifact you're looking for:

 http://shale.apache.org/shale-tiles/project-summary.html

 If there are further questions, we should probably move this to the
 user list.

 -Rahul



   -= Gregg =-
 






signature.asc
Description: OpenPGP digital signature


Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]

2007-01-15 Thread Greg Reddin

On 1/15/07, Kailas Lovlekar [EMAIL PROTECTED] wrote:


Shale is listed at version 1.1.0
All the pom.xml files show 1.1.0-SNAPSHOT, not sure how 1.0.4 was
derived for next release.




I believe it's just an iteration.  When we got 1.0.4 ready we renamed the
trunk to 1.1.0-SNAPSHOT expecting that to be the next major release.  That
doesn't mean there won't be anymore 1.0.x releases, but I think it means
they will take place in the 1.0 branch.

Greg


Re: [FWD: [v1.0.4] shale-tiles and release notes (was Re: svn commit: r490857 ...)]

2007-01-15 Thread Craig McClanahan

On 1/15/07, Greg Reddin [EMAIL PROTECTED] wrote:


On 1/15/07, Kailas Lovlekar [EMAIL PROTECTED] wrote:

 Shale is listed at version 1.1.0
 All the pom.xml files show 1.1.0-SNAPSHOT, not sure how 1.0.4 was
 derived for next release.



I believe it's just an iteration.  When we got 1.0.4 ready we renamed the
trunk to 1.1.0-SNAPSHOT expecting that to be the next major release.  That
doesn't mean there won't be anymore 1.0.x releases, but I think it means
they will take place in the 1.0 branch.



That is correct.  To summarize the state of things:

* The website always shows the latest and greatest version of
 the website from the trunk (which is now targeted towards 1.1)

* Version 1.0.4 is in the process of being released.  One of the
 tasks along that way is a link (on the front page) to a static
 copy of the website as it was for that version.  This is not done
 yet but still needs to be.

* In the future, we're planning on two track development:

 - New features, in addition to bugfixes, go into the trunk
   targeting 1.1.x.

 - We have a branch for 1.0.x so we can do any needed
   emergency fixes to 1.0.4, without having to force the
   user to accept all of the new features on the trunk that
   might not be stable yet.

 - In general, you can assume that new features will *not*
   be backported from the trunk.  The whole idea is that we
   can turn around very quickly on bugfix or security vulnerability
   issues that might come up, with disrupting existing applications
   that are using the latest released version.

 - When a 1.1.x release achieves feature completeness, the
   cycle will start again ... the trunk will switch to 1.2 or perhaps
   2.0, and there will be a maintenance branch for 1.1.

We're setting this approach up deliberately to avoid some of the long lead
time for a release issues that have affected projects like Struts and
MyFaces, where it was difficult to do bugfixes quickly because everything
happened on the trunk (no branches).  We aim to do better than that.


Greg




Craig