Lucene - Core
  1. Lucene - Core
  2. LUCENE-3163

CHANGES.txt has no release date for 3.1.0

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.2, 3.3, 4.0-ALPHA
    • Component/s: None
    • Labels:
    • Lucene Fields:
      New

      Description

      CHANGES.txt has no release date for 3.1.0 - although we've stopped putting dates on RCs' CHANGES.txt for the release-to-be, we should add dates to CHANGES.txt for past releases.

      Alternatively we could remove releases dates for past release completely.

        Activity

        Hide
        Robert Muir added a comment -

        Upon review, many previous lucene releases had no date here, and solr stopped putting them in a long time ago.

        If someone is a historian, they can use the apache mail archives or websites or something else to discover all these dates... lets make it one less hassle.

        Show
        Robert Muir added a comment - Upon review, many previous lucene releases had no date here, and solr stopped putting them in a long time ago. If someone is a historian, they can use the apache mail archives or websites or something else to discover all these dates... lets make it one less hassle.
        Hide
        Robert Muir added a comment -

        Committed revision 1129427 (trunk), 1129430 (branch_3x), 1129432 (branch32).

        When merging back from trunk, I noticed branch_3x got a merge conflict because the entire 2.9.4/3.0.3 section was missing, I added this from trunk to both these branches so that the CHANGES.txt files are properly synchronized.

        Show
        Robert Muir added a comment - Committed revision 1129427 (trunk), 1129430 (branch_3x), 1129432 (branch32). When merging back from trunk, I noticed branch_3x got a merge conflict because the entire 2.9.4/3.0.3 section was missing, I added this from trunk to both these branches so that the CHANGES.txt files are properly synchronized.
        Hide
        Steve Rowe added a comment -

        Upon review, many previous lucene releases had no date here, and solr stopped putting them in a long time ago.

        If someone is a historian, they can use the apache mail archives or websites or something else to discover all these dates... lets make it one less hassle.

        I don't like this. It really pisses me off when I look at release notes and nothing anchors the releases to dates. Having to look elsewhere sucks big time. Release numbers plus relative time between releases contains information that's helpful to people when they decide what release to choose. You removed useful information.

        I'm guessing your motivation, Robert, was to reduce release friction. I support that motivation. But I didn't say that the missing date should block the release, so as far as I'm concerned, release friction reduction doesn't cut it as motivation for this change.

        I want to put back the release dates.

        I'm open to other opinions.

        Show
        Steve Rowe added a comment - Upon review, many previous lucene releases had no date here, and solr stopped putting them in a long time ago. If someone is a historian, they can use the apache mail archives or websites or something else to discover all these dates... lets make it one less hassle. I don't like this. It really pisses me off when I look at release notes and nothing anchors the releases to dates. Having to look elsewhere sucks big time. Release numbers plus relative time between releases contains information that's helpful to people when they decide what release to choose. You removed useful information. I'm guessing your motivation, Robert, was to reduce release friction. I support that motivation. But I didn't say that the missing date should block the release, so as far as I'm concerned, release friction reduction doesn't cut it as motivation for this change. I want to put back the release dates. I'm open to other opinions.
        Hide
        Robert Muir added a comment -

        Steven, well you can look through the CHANGES.txt before my commit and see that in Lucene, many releases have no date (like most of the 1.x series).
        Additionally Solr stopped doing this about 1.4 (instead just saying "see the website for the date").

        I really don't like the dates, I'm sorry. The only thing the dates do is create another thing to update, with no clear benefit to anyone.
        Our goal here is to create open source releases... not maintain a historical record... these dates make releasing harder.

        If we must have dates in CHANGES.txt, then I vote to remove CHANGES.txt completely rather than make releasing so difficult!!!!

        Show
        Robert Muir added a comment - Steven, well you can look through the CHANGES.txt before my commit and see that in Lucene, many releases have no date (like most of the 1.x series). Additionally Solr stopped doing this about 1.4 (instead just saying "see the website for the date"). I really don't like the dates, I'm sorry. The only thing the dates do is create another thing to update, with no clear benefit to anyone. Our goal here is to create open source releases... not maintain a historical record... these dates make releasing harder. If we must have dates in CHANGES.txt, then I vote to remove CHANGES.txt completely rather than make releasing so difficult!!!!
        Hide
        Robert Muir added a comment -

        also, someone can find the release dates in JIRA.

        we could link this to the top of CHANGES.txt: https://issues.apache.org/jira/browse/LUCENE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

        This way, we don't have to deal with these dates in the actual file.

        Show
        Robert Muir added a comment - also, someone can find the release dates in JIRA. we could link this to the top of CHANGES.txt: https://issues.apache.org/jira/browse/LUCENE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel This way, we don't have to deal with these dates in the actual file.
        Hide
        Steve Rowe added a comment -

        with no clear benefit to anyone.

        I seriously disagree with this assertion. I personally look for dates to help me understand the release history on a project. There is a clear benefit to me as a user of software, and I don't think I'm alone.

        If we must have dates in CHANGES.txt, then I vote to remove CHANGES.txt completely rather than make releasing so difficult!!!!

        Putting a date into a file is difficult? After a release has been rolled out, not as a precondition for the release? Sorry, Robert, I don't buy it.

        Show
        Steve Rowe added a comment - with no clear benefit to anyone. I seriously disagree with this assertion. I personally look for dates to help me understand the release history on a project. There is a clear benefit to me as a user of software, and I don't think I'm alone. If we must have dates in CHANGES.txt, then I vote to remove CHANGES.txt completely rather than make releasing so difficult!!!! Putting a date into a file is difficult? After a release has been rolled out, not as a precondition for the release? Sorry, Robert, I don't buy it.
        Hide
        Robert Muir added a comment -

        Putting a date into a file is difficult? After a release has been rolled out, not as a precondition for the release? Sorry, Robert, I don't buy it.

        Yes, it makes releasing more difficult. we really need to reduce the amount of little things we have to do to take a release.
        we have 12 fucking changes files 2 branches (stable and trunk) to maintain.

        Removing these dates is 24 less little things i have to do to make a release... thats a pretty big deal. I'm gonna do everything I can to tone down what we have to do to make a release.

        Show
        Robert Muir added a comment - Putting a date into a file is difficult? After a release has been rolled out, not as a precondition for the release? Sorry, Robert, I don't buy it. Yes, it makes releasing more difficult. we really need to reduce the amount of little things we have to do to take a release. we have 12 fucking changes files 2 branches (stable and trunk) to maintain. Removing these dates is 24 less little things i have to do to make a release... thats a pretty big deal. I'm gonna do everything I can to tone down what we have to do to make a release.
        Hide
        Steve Rowe added a comment -

        also, someone can find the release dates in JIRA.

        we could link this to the top of CHANGES.txt: https://issues.apache.org/jira/browse/LUCENE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel

        This way, we don't have to deal with these dates in the actual file.

        I didn't know about this functionality. I think putting this link in the CHANGES.txt files is an acceptable alternative to dates in the CHANGES.txt files themselves.

        Show
        Steve Rowe added a comment - also, someone can find the release dates in JIRA. we could link this to the top of CHANGES.txt: https://issues.apache.org/jira/browse/LUCENE#selectedTab=com.atlassian.jira.plugin.system.project%3Aversions-panel This way, we don't have to deal with these dates in the actual file. I didn't know about this functionality. I think putting this link in the CHANGES.txt files is an acceptable alternative to dates in the CHANGES.txt files themselves.
        Hide
        Robert Muir added a comment -

        I didn't know about this functionality. I think putting this link in the CHANGES.txt files is an acceptable alternative to dates in the CHANGES.txt files themselves.

        OK, but lets do this for 3.3, 4.0?

        If it really makes you that upset, i'd rather put the link in the actual release email than respin.

        Show
        Robert Muir added a comment - I didn't know about this functionality. I think putting this link in the CHANGES.txt files is an acceptable alternative to dates in the CHANGES.txt files themselves. OK, but lets do this for 3.3, 4.0? If it really makes you that upset, i'd rather put the link in the actual release email than respin.
        Hide
        Steve Rowe added a comment -

        OK, but lets do this for 3.3, 4.0?

        If it really makes you that upset, i'd rather put the link in the actual release email than respin.

        Like I said on my email review of RC1, the release date thing is not a release blocker for me, so that sounds like a fine plan to me.

        BTW, this shorter URL works for me: https://issues.apache.org/jira/browse/LUCENE#selectedTab=versions-panel

        Show
        Steve Rowe added a comment - OK, but lets do this for 3.3, 4.0? If it really makes you that upset, i'd rather put the link in the actual release email than respin. Like I said on my email review of RC1, the release date thing is not a release blocker for me, so that sounds like a fine plan to me. BTW, this shorter URL works for me: https://issues.apache.org/jira/browse/LUCENE#selectedTab=versions-panel
        Hide
        Robert Muir added a comment -

        BTW, this shorter URL works for me: https://issues.apache.org/jira/browse/LUCENE#selectedTab=versions-panel

        Great, this is much shorter (we can always make it even shorter with an s.apache.org if we want, and you can choose the actual link text if its not taken, like i did for the release candidate link)

        Show
        Robert Muir added a comment - BTW, this shorter URL works for me: https://issues.apache.org/jira/browse/LUCENE#selectedTab=versions-panel Great, this is much shorter (we can always make it even shorter with an s.apache.org if we want, and you can choose the actual link text if its not taken, like i did for the release candidate link)
        Hide
        Steve Rowe added a comment -

        Removing these dates is 24 less little things i have to do to make a release... thats a pretty big deal. I'm gonna do everything I can to tone down what we have to do to make a release.

        I really do appreciate the work you're doing to make releasing simpler.

        Show
        Steve Rowe added a comment - Removing these dates is 24 less little things i have to do to make a release... thats a pretty big deal. I'm gonna do everything I can to tone down what we have to do to make a release. I really do appreciate the work you're doing to make releasing simpler.
        Hide
        Robert Muir added a comment -

        Bulk closing for 3.2

        Show
        Robert Muir added a comment - Bulk closing for 3.2

          People

          • Assignee:
            Robert Muir
            Reporter:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development