If an open issue has a fix version of the version being released it will automatically be updated to the next version.
Sent from my iPad > On Jul 18, 2014, at 9:57 PM, Remko Popma <[email protected]> wrote: > > Thanks! > > I'm using Jira at work but I don't think marking a version as released > automatically modifies the fix version of outstanding issues (unless I'm > missing something). > > Sent from my iPhone > >> On 2014/07/19, at 1:45, Ralph Goers <[email protected]> wrote: >> >> It should be now. I didn’t want to do that at the time because it would have >> moved everything to 2.0.1. You manually did the work so it should all be >> good now. >> >> Ralph >> >>> On Jul 18, 2014, at 9:27 AM, Remko Popma <[email protected]> wrote: >>> >>> Not a big deal, but in Jira, version 2.0 is still marked as not yet >>> released. >>> >>> >>>> On Fri, Jul 18, 2014 at 1:00 AM, Remko Popma <[email protected]> wrote: >>>> I finished the manual page on Custom Log Levels and Custom Loggers and >>>> committed to trunk. >>>> Please take a look. Feedback is welcome! >>>> >>>> >>>>> On Thu, Jul 17, 2014 at 1:52 AM, Remko Popma <[email protected]> >>>>> wrote: >>>>> Thanks! >>>>> >>>>> >>>>>> On Thu, Jul 17, 2014 at 1:32 AM, Ralph Goers >>>>>> <[email protected]> wrote: >>>>>> I have added 2.0.1 to Jira. >>>>>> >>>>>> Ralph >>>>>> >>>>>>> On Jul 16, 2014, at 8:43 AM, Remko Popma <[email protected]> wrote: >>>>>>> >>>>>>> Sounds good. I'll hold off on the Binary Logging, Memory-Mapped >>>>>>> Appender and config improvements to replace system properties that I >>>>>>> would like to see in a 2.1 release. >>>>>>> >>>>>>> I will try to finish the manual page for Custom/Extended Loggers in >>>>>>> time for the 2.0.1 release. >>>>>>> >>>>>>> Ralph, can you create a 2.0.1 release in Jira (and mark 2.0 as >>>>>>> released)? Several issues were fixed after the 2.0 vote started that >>>>>>> now have 2.1 as their fix version. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Thu, Jul 17, 2014 at 12:32 AM, Ralph Goers >>>>>>>> <[email protected]> wrote: >>>>>>>> I agree. >>>>>>>> >>>>>>>> I think we should take the approach that the next version will be a >>>>>>>> patch release, not a minor version and only change to a minor version >>>>>>>> if required. IOW, the current pom.xml files should all specify >>>>>>>> 2.0.1-SNAPSHOT as the version instead of 2.1-SNAPSHOT. This isn’t a >>>>>>>> big deal as it can be fixed during the release but it would be nice if >>>>>>>> the SNAPSHOT version always reflected what the next release is >>>>>>>> actually going to be. >>>>>>>> >>>>>>>> Ralph >>>>>>>> >>>>>>>>> On Jul 16, 2014, at 8:14 AM, Gary Gregory <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Now that 2.0 is done, I think it would be nice to see a 2.0.1 as soon >>>>>>>>> as we resolve the last of the Android issue from the current batch. >>>>>>>>> >>>>>>>>> We can advertise 2.0.1 as the "Android" release which also include >>>>>>>>> whatever tidbits (better status logger) have made it into trunk. >>>>>>>>> >>>>>>>>> I suggest this now while Ralph still has his RM hat on and we have a >>>>>>>>> user that has been quite helpful on testing Android patches. And we >>>>>>>>> are also all till in the releasing mindset and are paying attention. >>>>>>>>> For 2.1, we can take a breath, and regroup. >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> Gary >>>>>>>>> >>>>>>>>> -- >>>>>>>>> E-Mail: [email protected] | [email protected] >>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>> JUnit in Action, Second Edition >>>>>>>>> Spring Batch in Action >>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>> Home: http://garygregory.com/ >>>>>>>>> Tweet! http://twitter.com/GaryGregory >>
