I guess the idea is that releases of Log4j 2 and log4j-scala should be
independent in both ways, right?

I think I have coordination between log4j-scala and Scala language covered
already.

On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <remko.po...@gmail.com> wrote:

> Mikael, you probably need to plan your versioning scheme to handle any
> combination of the following:
> * log4j 2 releases: do you want to do a release for the log4j-scala modules
> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that
> once they are decoupled, the log4j-scala modules won't be released
> automatically with log4j anymore, someone needs to do the work for
> a log4j-scala release separately.
> * Scala releases: how do you want to sync up with Scala language versions?
> (I guess include major&minor Scala version in the log4j-scala module
> version)
> * log4j-scala module versions: enhancements to these modules, independent
> of the above
>
>
> Sent from my iPhone
>
> On Mar 3, 2017, at 9:10, Mikael Ståldal <mikael.stal...@magine.com> wrote:
>
> I would like to keep package and artifact names, and bump version to 11.0.
>
> On Mar 1, 2017 4:04 PM, "Matt Sicker" <boa...@gmail.com> wrote:
>
>> If you change artifact ids, it's generally a good idea to change
>> packages, too. I've had issues in the past with Feign for instance because
>> they changed groupId/artifactId at one point but kept the same API, so I
>> had two copies on the classpath until I found out there was a duplicate and
>> excluded them (though admittedly not a problem in OSGi environments :P).
>>
>> On 1 March 2017 at 07:47, Ralph Goers <ralph.go...@dslextreme.com> wrote:
>>
>>> You can do that, but that will probably confuse users too. I would
>>> suggest changing the artifactId and then start at either 1.0 or 2.0.
>>>
>>> Ralph
>>>
>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mikael.stal...@magine.com>
>>> wrote:
>>>
>>> OK, but then at least we have to start with a version > 2.8.
>>>
>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.go...@dslextreme.com>
>>> wrote:
>>>
>>>> I guarantee if you try to keep the same versioning you will regret it.
>>>>
>>>> Ralph
>>>>
>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mikael.stal...@magine.com>
>>>> wrote:
>>>>
>>>> I was under the impression that we were not ready to integrate the site
>>>> from log4j-scala. That's why I considered the release of log4j-scala as
>>>> delayed, since there is no point of releasing it if we cannot get the site
>>>> integrated.
>>>>
>>>> But now when Ralph says he's ready to integrate the site, I guess we
>>>> can go ahead and release log4j-scala.
>>>>
>>>> I don't like the idea of having separate versioning for log4j-scala,
>>>> that will be confusing since we have already started with the same
>>>> versioning as Log4j. Log4j-scala also have a dependency on log4j-api, and I
>>>> think we want to keep that in sync.
>>>>
>>>>
>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>
>>>>> One issue we came across in practice is that Scala 2.12 requires Java
>>>>> 8, but we don't want to require that for the entire build, so we separated
>>>>> the repo. This also helps avoid making the main log4j repo from taking
>>>>> forever to build and release which can help the RERO idea. Plus, these
>>>>> non-core modules don't change nearly as often as log4j-core or log4j-api,
>>>>> so they don't really need new releases all that often.
>>>>>
>>>>> On 28 February 2017 at 01:44, Remko Popma <remko.po...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> To be honest I still don't understand
>>>>>>
>>>>>> * the vision of what we ultimately want to achieve
>>>>>> * how different repos fit into that vision
>>>>>> * what different websites we are planning to create to give users
>>>>>> access to these different modules
>>>>>> * what websites are going to be driven from which modules or projects
>>>>>> * who of us is going to be driving what aspect of the above
>>>>>>
>>>>>> My lack of understanding is not just limited to the Scala modules but
>>>>>> is about the whole splitting up the release.
>>>>>>
>>>>>> Perhaps a diagram would help clarify my understanding. (I think
>>>>>> there's already a JIRA or an epic for the above. Adding some diagrams 
>>>>>> there
>>>>>> would be very useful.)
>>>>>>
>>>>>> Remko
>>>>>>
>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <boa...@gmail.com> wrote:
>>>>>>
>>>>>>> I'd be in favour of starting a new release train for the Log4j Scala
>>>>>>> APIs. Not exactly sure which version to start from, though.
>>>>>>>
>>>>>>> On 27 February 2017 at 18:35, Ralph Goers <
>>>>>>> ralph.go...@dslextreme.com> wrote:
>>>>>>>
>>>>>>> If you use that excuse they will never get released as it creates a
>>>>>>> catch-22.  If I release without them then we have a regression until 
>>>>>>> they
>>>>>>> are released.
>>>>>>>
>>>>>>> This is why you shouldn’t really be releasing them using the Log4j
>>>>>>> versions. Change the artifactIds so they can start at 1.0, 2.0 or 
>>>>>>> whatever.
>>>>>>>
>>>>>>> Once you create the release and deploy it to the web site I can
>>>>>>> modify the web site to point to it.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>
>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it
>>>>>>> harder to release from the log4j-scala repo when two of the three 
>>>>>>> artifacts
>>>>>>> will already exist.
>>>>>>>
>>>>>>> On 27 February 2017 at 12:14, Ralph Goers <
>>>>>>> ralph.go...@dslextreme.com> wrote:
>>>>>>>
>>>>>>> Why is the release of log4j-scala delayed?
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>>>> mikael.stal...@magine.com> wrote:
>>>>>>>
>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next
>>>>>>> release.
>>>>>>>
>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo since I
>>>>>>> thought that it would be released as part of 2.8, otherwise I would have
>>>>>>> put it to the main repo as well. But now releasing of the log4j-scala 
>>>>>>> repo
>>>>>>> has been delayed and I start to get disappointed.
>>>>>>>
>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <boa...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Relative symlinks would work for that regardless of version. Option
>>>>>>> 1 it is, then?
>>>>>>>
>>>>>>> On 25 February 2017 at 00:22, Apache <ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Note that the link in the log4j site can reference a symlink so that
>>>>>>> the log4j site never has to change when the Scala site is updated.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache <ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Option 2 makes no sense to me.  I don’t plan on being the release
>>>>>>> manager for log4j-scala. In order for me to implement option 2 I would 
>>>>>>> have
>>>>>>> to include the log4j-scala site into the log4j release process - as 
>>>>>>> well as
>>>>>>> log4j-examples, etc if they move out. That is just not doable. Deploying
>>>>>>> the Scala site parallel to log4j makes it much easier to maintain
>>>>>>> independently of log4j.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>
>>>>>>> The site repository is laid out like this:
>>>>>>>
>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/
>>>>>>> log4j/log4j-2.8/log4j-api/
>>>>>>> ...
>>>>>>> log4j/2.x/log4j-api-scala_2.11/
>>>>>>>
>>>>>>> Option 1 is to put it here instead:
>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a
>>>>>>> pretty ugly URL honestly)
>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory
>>>>>>>
>>>>>>> Option 2 is to commit the scala site where it is now, but you'd have
>>>>>>> to manage it alongside log4j core releases. Option 1 still requires
>>>>>>> maintenance, too.
>>>>>>>
>>>>>>> On 25 February 2017 at 00:05, Apache <ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> There is a specific location in svn where the site pages have to be
>>>>>>> committed, so I don’t really understand option 1.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>
>>>>>>> I see two ways of doing that, though:
>>>>>>>
>>>>>>> 1. Commit the Scala site in a separate directory similar to what I
>>>>>>> started doing with Log4j Boot. Add redirect pages or rewrite rules via
>>>>>>> .htaccess if possible to keep links from breaking.
>>>>>>> 2. Commit the Scala site where it would go when creating the main
>>>>>>> site. Depending on how you update the files in svn for a site update, 
>>>>>>> could
>>>>>>> this be more annoying to maintain?
>>>>>>>
>>>>>>> On 24 February 2017 at 22:30, Apache <ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> From my perspective that doesn’t matter. However, we would really
>>>>>>> need a Scala site before we can modify the Log4j site, otherwise it 
>>>>>>> will be
>>>>>>> a dead link.
>>>>>>>
>>>>>>> All that really needs to happen is the Scala site needs to be
>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site just has 
>>>>>>> a
>>>>>>> link to the Scala site from the main menu. The two sites won’t really be
>>>>>>> “integrated” - they will just have links to each other.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boa...@gmail.com> wrote:
>>>>>>>
>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module.
>>>>>>>
>>>>>>> On 24 February 2017 at 14:17, Apache <ralph.go...@dslextreme.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I don’t have the numbers but I have a couple of issues that need
>>>>>>> fixes.
>>>>>>>
>>>>>>> The modules stuff doesn’t require a major version bump. It is mostly
>>>>>>> cosmetic.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgreg...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving modules
>>>>>>> around feels like a 2.9 item to me but that's just me. I really like the
>>>>>>> idea of making bug fixes available ASAP. The only issue I see that 
>>>>>>> fixing
>>>>>>> now is the null classloader issue for which we have a patch but it does 
>>>>>>> not
>>>>>>> work for me (see JIRA).
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boa...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I'm hoping we can get this released soon as we have some bugfixes
>>>>>>> and such ready to go. I also want to move forward with 2.9 changes but
>>>>>>> don't really want to deal with creating a 2.9 branch or forking master 
>>>>>>> into
>>>>>>> a 2.8 branch. Let's go over anything left to do for 2.8.1:
>>>>>>>
>>>>>>> * Integrated log4j-api-scala website into main site
>>>>>>> * Remove scala modules from logging-log4j2 repo
>>>>>>> * Release scala modules from logging-log4j-scala repo (presumably
>>>>>>> shortly after releasing 2.8.1 of core?)
>>>>>>>
>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, but
>>>>>>> that's for another day. I think getting everything working properly in 
>>>>>>> Java
>>>>>>> 9 would be a good thing to start doing soon so we can figure out if our
>>>>>>> APIs will still work properly in the future or if we need to break
>>>>>>> backwards compatibility. Although, multi-jar support could help in
>>>>>>> migrating the API if needed for 9+, though that would be a rather
>>>>>>> unorthodox abuse of the feature.
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>>>>>>>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
>>>>>>> JUnit in Action, Second Edition
>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>>>>>>>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
>>>>>>> Spring Batch in Action
>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
>>>>>>> Blog: http://garygregory.wordpress.com
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> [image: MagineTV]
>>>>>>>
>>>>>>> *Mikael Ståldal*
>>>>>>> Senior software developer
>>>>>>>
>>>>>>> *Magine TV*
>>>>>>> mikael.stal...@magine.com
>>>>>>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>>>>>>>
>>>>>>> Privileged and/or Confidential Information may be contained in this
>>>>>>> message. If you are not the addressee indicated in this message
>>>>>>> (or responsible for delivery of the message to such a person), you
>>>>>>> may not copy or deliver this message to anyone. In such case,
>>>>>>> you should destroy this message and kindly notify the sender by
>>>>>>> reply email.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Matt Sicker <boa...@gmail.com>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boa...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> [image: MagineTV]
>>>>
>>>> *Mikael Ståldal*
>>>> Senior software developer
>>>>
>>>> *Magine TV*
>>>> mikael.stal...@magine.com
>>>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>>>>
>>>> Privileged and/or Confidential Information may be contained in this
>>>> message. If you are not the addressee indicated in this message
>>>> (or responsible for delivery of the message to such a person), you may
>>>> not copy or deliver this message to anyone. In such case,
>>>> you should destroy this message and kindly notify the sender by reply
>>>> email.
>>>>
>>>>
>>>
>>>
>>> --
>>> [image: MagineTV]
>>>
>>> *Mikael Ståldal*
>>> Senior software developer
>>>
>>> *Magine TV*
>>> mikael.stal...@magine.com
>>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>>>
>>> Privileged and/or Confidential Information may be contained in this
>>> message. If you are not the addressee indicated in this message
>>> (or responsible for delivery of the message to such a person), you may
>>> not copy or deliver this message to anyone. In such case,
>>> you should destroy this message and kindly notify the sender by reply
>>> email.
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <boa...@gmail.com>
>>
>


-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Reply via email to