Cocoalumberjack: 2.0.1

[plandem]

again breaking backward compatibility?

Code that was working fine with 2.0.0, does not work at 2.0.1 anymore.

Error:(74, 3) use of undeclared identifier 'ddLogLevel'

[bpoplauschi]

We had an issue with ddLogLevel which had to be fixed. Basically, you still need to define it.

[plandem]

as i said....at 2.0.0 it's working fine. and yes, at my code i have:

#if DEBUG
    static const DDLogLevel ddLogLevel = DDLogLevelVerbose;
#else
    static const DDLogLevel ddLogLevel = DDLogLevelWarning;
#endif

[bpoplauschi]

Where is your definition of ddLogLevel? I usually set it in the precompiled header, next to #import <CocoaLumberjack.h>

[plandem]

it's long story. right now it's a library from another cocoapod. but, as i said, at 2.0.0 it's working fine.

[markcleonard]

Have the same situation as @plandem. We use CocoaLumberjack in a shared framework between apps, which was working fine in 2.0.0 and is now broken in 2.0.1 for the same reason.

[colinbrash]

We are experiencing the same issue. I don't fully understand, "you still need to define [ddLogLevel]". We did not have to define it in 2.0.0. Changing this behavior in a patch version seems wrong.

[bpoplauschi]

Guys, the fix from 2.0.0 that allowed you to skip defining ddLogLevel was reported as a bug https://github.com/CocoaLumberjack/CocoaLumberjack/issues/478. Since we didn't have a good fix for that, I thought we just revert it. Sorry for the inconvenience, but it should be an easy fix to make sure ddLogLevel is defined.

[plandem]

but in my case i HAVE ddLogLevel

[jtdavid]

I also have ddLogLevel and still have the issue as @plandem refered. I do have a private repo with CocoaLumberjack as dependency in my embed framework podspec...

[bpoplauschi]

Guys, are you perhaps using Swift? I cannot understand why this issue occurs, if ddLogLevel is defined.

[markcleonard]

In our case we have lumberjack in a shared framework that we use among different projects. Log levels are not defined in the framework itself, but in the projects. So 2.0.1 could not build as a part of our framework anymore.

[bpoplauschi]

What I can't really grasp is the following fact. 1.9.x required to define ddLogLevel. 2.0 removed that, 2.0.1 reverted to the state of 1.9.x, but people keep getting errors with 2.0.1. I can't understand what the course of action should be

[plandem]

what about fact that it defined, but still not working? As i said, i have:

#if DEBUG
    static const DDLogLevel ddLogLevel = DDLogLevelVerbose;
#else
    static const DDLogLevel ddLogLevel = DDLogLevelWarning;
#endif

[bpoplauschi]

Yes, but the error is probably due to the fact that one of your pods is using Lumberjack and it doesn't have a ddLogLevel.

Honestly, I don't know how to fix this. If we use the old approach (requiring ddLogLevel), we got issues like @plandem. But if we revert to the 1.9.x, then we screw up the logging levels as described in #478.

@rivera-ernesto @robbiehanson @dvor any ideas?

[plandem]

ddLogLevel defined at library pod. any other pod using lumberjack via that library pod. maybe some post install settings for pod?

[rivera-ernesto]

As it was a x.x.1 minor version update, we should keep 2.0.0 behavior.

[plandem]

+1 for 2.0.0 behaviour. It's critical when minor update breaks the backward compatibility.

[rmaloney3]

I agree with the others. CocoaPods uses semantic versioning, which allows us to specify pod 'CocoaLumberjack', '~> 2.0', and receive any version 2.0.x, with the understanding that there will be NO API changes. This change is breaking that system. Even though it was a bug fix, since it is an API change, it should not be included (or at the very least, required) until the 2.1 release.

[d-amend]

I solved it by writing extern const DDLogLevel ddLogLevel; in the header of the file that defines ddLogLevel and importing that header in every file that uses DDLog... . (I do not use the pch-file)

[rivera-ernesto]

In that case we should still make it a 2.1.0 release as requires API changes, and probably make a compatibility fixing 2.0.2 release as well.

[OliverDobner-flinc]

I have the same problem (2.0.0 worked for me, 2.0.1 not) as I do not have a precompiled header. (new Xcode objective c projects don't have one!!)
So please keep/recreate the 2.0.0 behavoir. As of swift coming without this, I think that using a precompiled header is outdated.

[jasonfergz]

We have CocoaLumberjack as a dependency for our pod (MMX) and when using 2.0.1 we get a non-modular header error. By using the bleeding edge(latest commits in master branch) it seems to resolve the issue. Are we close to a 2.0.2 release?

[rivera-ernesto]

Now that we have new 2.0.2 and 2.0.3 releases do you get 2.0.0 compatibility back?

[bpoplauschi]

Will reopen if it's still the case

[rmaloney3]

2.0.3 still has the requirement of defining ddLogLevel at the top of each file. As @OliverMahn-flinc mentioned, Xcode's project templates no longer include precompiled headers, and as such, I wouldn't consider that a viable solution.

The fact remains that 2.0.0 set an API, and ever since 2.0.1 that API has been broken. Please don't require that ddLogLevel be defined until 2.1.0 in order to preserve API compatibility.

Also, I don't believe it should be a requirement to define ddLogLevel in every file. It's nice to have the option to set log level per file, but this is more of a power-user feature, and as such should not be required to use the API. Why not extern the definition of ddLogLevel in DDLog.h, and let people override it if they want?

[rivera-ernesto]

I agree that we should reestablish 2.0.0 compatibility for 2.0.x releases but we should also feel free to choose the best solution for 2.1.0 even if we break the API again.

It is also a good timing to propose both as pull requests.

[bpoplauschi]

Not sure how to handle this case now. I thought that #539 did the trick, as we reverted to the old way we did things (requiring ddLogLevel defined in every file that was logging). Precompiled headers can still be added, but of course that the default Xcode template without a pch will push people towards not using it. The problem is, if we make another change like that (even though we don't have a solid one right now), it will break compatibility.

[xiaoboJoin]

2.2.0 still : Use of undeclared identifier "ddLogLevel"?
how do i fix it ?

[bpoplauschi]

You need to define the ddLogLevel. The easiest way is to add this to a pch (precompiled header), if you have any:
static const int ddLogLevel = DDLogLevelDebug;
Otherwise, you need to define this ddLogLevel in each file that uses tracking.

[OliverDobner-flinc]

Is this really the wanted behavior that I have to add this line to hundreds of files? In 2.0.0 I don't needed this, so I can't imagine why it is an improvement to force the developer to maintain hundreds of lines of code that are exactly the same.
I agree that this should be possible, but not necessary.

[bpoplauschi]

This was the behavior we always had, in 2.0.0 there was an exception since we tried a different mechanism but that was breaking changes for other people. Unfortunately, we don't have a good solution for this, so until we do, Obj-C users are stuck with this ddLogLevel config. I advise you add a pch to your project if you don't have one so you don't duplicate the ddLogLevel everywhere

[rivera-ernesto]

Is the 2.0.0 change we made to allow people to start using the library right away without defining a ddLogLevel?

If so I think that was a good approach for people new to the library while allowing advanced users to define their own. We just have to avoid making that change in a minor revision change.

[OliverDobner-flinc]

In 2.0.0. you could do something like this:
[DDLog addLogger:[DDTTYLogger sharedInstance] withLevel:DDLogLevelError];

One line to define logger and log level for the whole application.This is great for starting with cocoa lumber jack.
As this was a major release number change I thought it was a new feature.