You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@struts.apache.org by bu...@apache.org on 2004/02/05 07:48:58 UTC

DO NOT REPLY [Bug 26677] New: - Provide more version number granularity in manifest.mf

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26677>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26677

Provide more version number granularity in manifest.mf

           Summary: Provide more version number granularity in manifest.mf
           Product: Struts
           Version: 1.1 Final
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Controller
        AssignedTo: struts-dev@jakarta.apache.org
        ReportedBy: duncan.mills@oracle.com


As a vendor implementing Struts Support into our IDE (Oracle JDeveloper) it
becomes important that we can detect exactly which version of Struts is
available and do the right thing accordingly. 
The situation with 1.1 was an example of this. There are DTD changes between the
final version and preview betas, but the manifest in both cases just has 1.1 as
the Implementation-Version.
I see from the nightly builds for 1.2 that the minor version is now being used
but is set to 0, e.g. 1.2.0.
Ideally a more granular numbering scheme should be adopted for 1.2, even down to
the level of nightlies being identified using a _suffix to the minor build
e.g. 1.2.<milestone>_<nightly> for a nightly build 
     1.2.<milestone> for a stable RC or Final

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org