DDFileLogger: fixed isLogFile: method for timestamp log naming convention

[dvor]

Issue #189.

isLogFile: method wasn't processing DDLogFileNamingConventionTimestamp. This if fixed now.

Also I've changed timestamp format. In previous format colons were automatically converted to slashes / due to file naming convention - colons are forbidden in file name.

[dvor]

@bpoplauschi @rivera-ernesto Now logs have .txt file format. Maybe there is sense to change it to .log?

[rivera-ernesto]

I think that's a good idea. That's what Apple does too.

Do you want to add that change here?

[rivera-ernesto]

In case we with to *.log the file prefix wouldn't be needed anymore.

Maybe something like MobileSafari 2013-12-03 17-14.log where you could easily distinguish logs.

[bpoplauschi]

I agree, this MobileSafari 2013-12-03 17-14.log looks right

[dvor]

This format looks good. But I think we should leave old formats for compatibility. Something like this:

typedef enum {
    // Application name followed by date.
    // Example: MobileSafari 2013-12-03 17-14.log
    DDLogFileNamingConventionDefault,

    // old file naming convetion, using UUID.
    // Example: log-DFFE99.txt
    DDLogFileNamingConventionUUID,

    // old file naming convention, using UTC time in RFC 3339 format.
    // Example: log-2013-12-20T15-20-30Z.txt
    DDLogFileNamingConventionTimestamp
} DDLogFileNamingConvention;

[rivera-ernesto]

Sure, if it's not too much hassle.

On the other hand there's not really a compatibility issue that would really break by using a new (and better) naming convention.

Personally I would keep only the last one as it already has both:

• A UUID (and a meaningful one) DDLogFileNamingConventionUUID.
• A timestamp, doh DDLogFileNamingConventionTimestamp.

This is easy to update for client apps, and more important, easier to maintain and test for us!

[rivera-ernesto]

Related to #174.

[dvor]

Well, then we can get rid of other formats and those enum. It simplifies the code.

The only thing that can be annoying for users is that DDLogFileNamingConvention would be removed and they'd have to modify their code.

[rivera-ernesto]

That would just be a one-time change for them.

[dvor]

#191 replaces this.

[rivera-ernesto]

About versioning. I just noticed that Pods-environent has:

// CocoaLumberjack
#define COCOAPODS_POD_AVAILABLE_CocoaLumberjack
// This library does not follow semantic-versioning,
// so we were not able to define version macros.
// Please contact the author.
// Version: 1.6.5.1.

// CocoaLumberjack/Core
#define COCOAPODS_POD_AVAILABLE_CocoaLumberjack_Core
// This library does not follow semantic-versioning,
// so we were not able to define version macros.
// Please contact the author.
// Version: 1.6.5.1.

// CocoaLumberjack/Extensions
#define COCOAPODS_POD_AVAILABLE_CocoaLumberjack_Extensions
// This library does not follow semantic-versioning,
// so we were not able to define version macros.
// Please contact the author.
// Version: 1.6.5.1.

[dvor]

@rivera-ernesto Will releasing new version with right tag fix this? Or we have to remove 1.6.5.1 tag (which could hurt some of users)?

If new version is enought, than we can release 1.7 with #191. Well, it could be 1.6.6, but as to me changing log file name format is MINOR change.

[bpoplauschi]

@rivera-ernesto Good catch. This was far from ideal, but I think releasing a 1.7 would get us back in trend. This way it will be easier to release a patch with 1.7.x, if needed.

[rivera-ernesto]

I would prefer keeping 1.6.x releases until we get some bigger changes.
That way we can also release more frequently (which is really important) without getting to 2.0 or 3.0 too fast (where the version is just a detail).

That said we should release now as #194 will require more work.

[bpoplauschi]

I can go with both 1.6.6 or 1.7.0, but I think there are more arguments in favour of 1.7.0:

• the feature set has changed significantly since 1.6.0, so we should show that in a minor release
• between 1.6.5.1 and the next version, we changed the repo from robbiehanson/CocoaLumberjack to CocoaLumberjack/CocoaLumberjack which is pretty significant, even though we should not affect anyone using Cocoapods
• the new log file naming convention is also a feature
• all those show we have new functionality that is backwards compatible instead of just fixes for a patch
• if by any chance we release 1.6.6 and we need to patch it, we could do 1.6.7 or 1.6.6.1 and both have their imperfections.

I'd suggest we start doing releases by the book.

[dvor]

without getting to 2.0 or 3.0 too fast

We don't have to release 2.0 at all. We can always go 1.10.0 and 1.11.0. ;)

[rivera-ernesto]

Ok, 1.7.0 ;)

Can you please do it? I have something to finish here...

[bpoplauschi]

Ok, will do this asap.

[bpoplauschi]

Release 1.7.0 is ready, Cocoapods specs pull request: CocoaPods/Specs#6295

[dvor]

Great! Thanks @bpoplauschi