Last time I checked (OK, several months ago), every migration file IS loaded for any migration..
That's a bug.
-1 on moving UTC timestamps inside the migration file.
Hey Pratik,
Could I ask why?
Cheers,
Nik
Hey Pratik,
Could I ask why?
We've gone back and forth so much on the file names for migrations I think people are beginning to lose sight of the fact that it's just not that important. There's a stack of other bugs and patches that could do with work...
As for why it's a bug, you and I have shared a project where we had to hack old migrations because they referred to classes which no longer existed. If we only required the migrations we needed to move forwards, then it wouldn't matter as often.
Finally, the backwards compatibility issues would far out weigh the aesthetically limited benefits in the change.
Hey Pratik,
Could I ask why?
We've gone back and forth so much on the file names for migrations I think people are beginning to lose sight of the fact that it's just not that important. There's a stack of other bugs and patches that could do with work...
Fair enough. 
As for why it's a bug, you and I have shared a project where we had to hack old migrations because they referred to classes which no longer existed. If we only required the migrations we needed to move forwards, then it wouldn't matter as often.
I totally understand why that's a bug - I've actually run into again recently. This change wouldn't stop a fix being put into place for that bug, and I can come up with a separate diff/patch that fixes that.
Finally, the backwards compatibility issues would far out weigh the aesthetically limited benefits in the change.
The patch works fine with any migrations that aren't timestamped inside the class, it just ignores them.
Come to think of it though, the UTC migrations will end up generating weird next-migration numbers.
I _really_ like the idea of getting the pretty-looking numeric migrations back, but if the tradeoffs aren't worth it, oh well.
Nik
Hey All,
Ok, at Koz's request I'll stop arguing about what brand the bikeshed
paint should be. 
I've updated the patch with a flipped default and a little documentation:
Cheers,
Nik
Pushed.
Thanks.
Won't this bite people who have both numbered and UTC migrations right now? Their migration numbers go:
1, 2 ... 20080715053417, 20080715053428.
And then they move to the next Rails release, flip the non-timestamp switch to true, and then what does their sequence look like?
1, 2, 3, 4 ... 20080715053417, 20080715053428.
Unless I'm missing something, that's not quite what they would expect, is it?
Nope, that's why their next migration will be 20080715053429 
Oh got it. So they have to explicitly renumber. Fun stuff.
Fun stuff indeed… which is why the default should false: for those who have not upgraded, this would save them the mess.
Fun stuff indeed... which is why the default should false: for those who have not upgraded, this would save them the mess.
The default won't be changed, we've already shipped a release with the timestamped migrations.
I'm really sorry that you feel so strongly about this issue and don't seem to be able to get past it, but there's nothing more to discuss.
I’m really sorry that you feel so strongly about this issue and don’t
seem to be able to get past it, but there’s nothing more to discuss.
I wasn’t keeping this thread alive, I had not commented in almost a week until I decided to agree with someone else.
I am was/am past it and would appreciate a better tone.
thanks, andy
I appreciate everyone’s efforts to make the problem and its solution explicit. A lot of people will suffer, and finding this thread will be very helpful.