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

Posted to dev@metron.apache.org by mattf-horton <gi...@git.apache.org> on 2017/09/19 22:42:38 UTC

[GitHub] metron pull request #767: METRON-1196 Increment master version number to 0.4...

GitHub user mattf-horton opened a pull request:

    https://github.com/apache/metron/pull/767

    METRON-1196 Increment master version number to 0.4.2 for on-going development

    ## Contributor Comments
    Standard update of the Metron version number.
    There are just a couple files where I changed a 0.4.0 to 0.4.1 to make a multi-line example self-consistent, that had been poorly edited in the past (probably by me).  The rest of it is all changing "0.4.1" to "0.4.2" where needed.
    
    If you grep for "0.4.1" (or rather for "0\.4\.1"), you'll find some remaining usage of 0.4.1 in documentation files, where I judged the usefulness of an example did not require updating the version number.  Also of course "0.4.1" persists in history and log files, and in usages related to package versions other than metron.
    
    
    ## Pull Request Checklist
    
    ### For all changes:
    - [x] Is there a JIRA ticket associated with this PR? If not one needs to be created at [Metron Jira](https://issues.apache.org/jira/browse/METRON/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel). 
    - [x] Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
    - [x] Has your PR been rebased against the latest commit within the target branch (typically master)?
    
    
    ### For code changes:
    - [NA] Have you included steps to reproduce the behavior or problem that is being changed or addressed?
    - [NA] Have you included steps or a guide to how the change may be verified and tested manually?
    - [x] Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
      ```
      mvn -q clean integration-test install && build_utils/verify_licenses.sh 
      ```
    
    - [NA] Have you written or updated unit tests and or integration tests to verify your changes?
    - [NA] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? 
    - [NA] Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?
    
    ### For documentation related changes:
    - [NA] Have you ensured that format looks appropriate for the output in which it is rendered by building and verifying the site-book? If not then run the following commands and the verify changes via `site-book/target/site/index.html`:
    
      ```
      cd site-book
      mvn site
      ```


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/mattf-horton/metron METRON-1196

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/metron/pull/767.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #767
    
----
commit 2ee45879fed27d5b8336d236db469d32a01e9ed3
Author: mattf-horton <mf...@hortonworks.com>
Date:   2017-09-19T22:35:39Z

    METRON-1196 Increment master version number to 0.4.2 for on-going development

----


---

[GitHub] metron issue #767: METRON-1196 Increment master version number to 0.4.2 for ...

Posted by mattf-horton <gi...@git.apache.org>.

Github user mattf-horton commented on the issue:

https://github.com/apache/metron/pull/767

@ottobackwards , regarding the version references in metron-analytics/metron-profiler/README.md:
This is a little difficult. Although these are installation instructions, the lines you grepped are all OUTPUT from `find` or `rpm`. In use with an 0.4.2 code base, the actual output will be the correct-in-that-context 0.4.2 filenames and pathnames. So while user might be surprised at first, they will not (if they're following instructions) be caused to type incorrect commands. And since 0.4.2 hasn't been released yet, there is no date field that I can substitute for `201707131420` would be "correct" with 0.4.2.

I think it's best to leave it the way it is. If you prefer a different rendering, please propose.

Regarding the line from metron-analytics/metron-profiler-client/README.md that has an 0.4.1, this is in the text of an example, and does not materially affect the example. Therefore, as noted in the opening comments of this PR, it is my policy to leave it unchanged. "If you grep for `0.4.1` (or rather for `0\\.4\\.1`), you'll find some remaining usage of 0.4.1 in documentation files, where I judged the usefulness of an example did not require updating the version number."

Open to discussion, of course. But by following this policy, those (many) lines of text fall out of the grep on the next generation (when moving from 0.4.2 to 0.4.3). Which makes release management much easier.

---

[GitHub] metron issue #767: METRON-1196 Increment master version number to 0.4.2 for ...

Posted by mattf-horton <gi...@git.apache.org>.

Github user mattf-horton commented on the issue:

    https://github.com/apache/metron/pull/767
  
    Needed to re-kick Travis to be sure.


---

[GitHub] metron issue #767: METRON-1196 Increment master version number to 0.4.2 for ...

Posted by mattf-horton <gi...@git.apache.org>.

Github user mattf-horton commented on the issue:

    https://github.com/apache/metron/pull/767
  
    Sorry about that, folks.  In future I won't trust github when it says it will still merge "without conflict".


---

[GitHub] metron issue #767: METRON-1196 Increment master version number to 0.4.2 for ...

Posted by kylerichardson <gi...@git.apache.org>.

Github user kylerichardson commented on the issue:

    https://github.com/apache/metron/pull/767
  
    There are so many `pom.xml` files to change. Have we considered using a metron_version property in the parent/root pom to avoid needing to change so many files in future releases? If folks agree, I'd be happy to do the leg work and submit a PR.


---